| Re: Re[4]: [higgins-dev] IdAS update proposals |
|
<oops, I replied to Valery only and this went off-list>
>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 4/17/07 6:59 AM >>>
>What I meant is that when people calls add/set/remove methods, CP >implementation could just create and hold update operations (like with >current methodology IdAS consumers must do prior to any update) instead >of update backed store. When people calls commit, CP implementation >updates backed store using held operations. So far, this describes both Option 1 and Option 3.a (when the transaction semantics are set to "OnCommit")
>Most likely this will require a hierarchical structure of update
>operations and the simplest way I could imagine is to define very >simple interface like: >interface IUpdateHolder { > Iterable<UpdateOperation> getUpdates(); > void addUpdate(UpdateOperation op); > void clearUpdates(); >} >and implement it by each substance in the context. When you use UpdateOperation here, do you mean as it exists today?
I'm pretty sure I'm confused at the intent. If we re-introduce add/remove methods to each substance in the context, will people not expect them to be committed realtime? I mean, will they always have to call a commit-like method with the list of updates?
Let me put out another variation on the proposal which I *think* is pretty close to what you're saying. I'll call it Option 3.b.
Jim
>Tuesday, April 17, 2007, 2:40:31 AM, you wrote: > > >> What would that look like? People would call things like >> addAttribute, etc. and then call update with the list of >> attributes? I'm trying to picture the APIs. <snip> |