Next Tasks

Darius, Christian, Julie:

• continue to work the history proposal
  *

Anders, Maros:

• Update the abstract section - it is a bit old, make it reflect the current thinking

• Hibernate interception used to generate the history: is this workable? Someone needs to prototype and decide this.

Discussion notes

• About the history tracking:

  • we were making assumptions that it is needed because knowing history may be needed to resolve conflicts; if this is not the case, it may not be the case

  • summary of the call from yesterday: history/auditing proposal makes sense, however there is an apprehension with respect to the

  • we can have a single 'change log': but we loose some (depends on how may columns we keep) of ER properties and it will be more difficult to join and search. This may be sufficient for sync (where we care about set of changes based on timestamps) but may be problematic if we want to make history available

  • next steps: do the prototype and show the impact

• Layering: there are a lot of layers - layering makes sense to provide encapsulation and modularity but it does add another level of indirection, and makes the perf optimization more difficult

  • this was evolved over time; we will not really have opportunity to change/impact this – take it as it is

  • given that: for example Hibernate is so entranched can/should we assume Hibernate it will be there and implement the generation of the history there

*