cascading replication on fields (optional) when solving conflicts 
Use this IdeaSpace to post ideas about Domino Designer.

: -10
: 0
: 10
: Domino Designer
: replication, fields, conflicts
: Hendrik Jan van Meerveld812 02 Oct 2009
: / Email
This would be a field setting. I don't see a way to implement this with scripting, so I would like to see it implemented in the replication procedure.
Suppose John adds $1.00 to the "totalamount" field and Susan adds $3.00 to the same "totalamount" field. When replicating this would then result in adding $4.00 to the "totalamount" field.
Same for text fields. When John adds "10/10/2009 16:29 John increased the total amount with $1.00" to the "log" field and Susan adds "10/10/2009 16:31 Susan increased the total amount with $3.00" to the "log" field. When replicating this would then result in adding "10/10/2009 16:29 John increased the total amount with $1.00 10/10/2009 16:31 Susan increased the total amount with $3.00" to the "log" field.

1) Peter Presnell28487 (03 Oct 2009)
I'm sorry but I don't understand. If a field has a value of $2 on two servers and two people each "add $1.00" making the value $3 on the two servers, when replication occurs how does either server know the original value was $2. They only know that the new value is $3 and that the value was changed on both servers. Notes does not keep a history of the changed values made.
2) Hendrik Jan van Meerveld812 (03 Oct 2009)
I see that implementing this would be a technical challenge.
Nonetheless this would be a real help in writing a financial application or in using a counting field.

Probably the field could remember it's changes.
The field would have a "original value after last replication with administration server" and it's actual value.
The values would then be combined when the field is replicating with the administration server.

I do not know how tricky this would be to implement. If it is difficult to add this extra information to the field, probably you could make the field single-value and use the multivalue part to remember the last replicated value.
3) Peter Neidhart1567 (04 Oct 2009)
This is plain application logic and I think this should not be part of the replicator.
4) Hendrik Jan van Meerveld812 (05 Oct 2009)
Programming this as application logic requires lots of code to maintain for the database developer. It would also require access to the administration database every time one such field is saved (because there is no such thing as a "onReplication" event that you can use).
Therefore I'd like to see this as a field option.
5) Bill Malchisky12192 (06 Jan 2010)
You can code this into an application if one is concerned, or at the least, add an audit trail to your app and merge it post replication/edits. I agree with @3, the replicator is fast and reliable...inserting artificial intelligence-esque logic would dampen one of the replicator's core strengths.


Welcome to IdeaJam

You can run IdeaJam™ in your company. It's easy to install, setup and customize. Your employees, partners and customers will immediately see results.

Use IdeaJam to:

  • Collect ideas from employees
  • Solicit feedback and suggestions from employees and customers
  • Run innovation contests and competitions
  • Validate concepts
  • Use the power of "crowd-sourcing" to rank ideas and allow the best ideas to rise to the top

IdeaJam™ works with:

  • IBM Connections
  • IBM Lotus Quickr
  • Blogs and Wikis
  • Websphere Portal
  • Microsoft Sharepoint
  • and other applications.

IdeaJam has an extensive set of widgets and API's that allow you to extend and integrate IdeaJam™ with other applications.

Learn more about IdeaJam >>

IdeaJam developed by

Elguji Software Logo