Thanks for the explanation, I think I have a better
understanding now.
So, I think what I got from that is that if I want to have control
over each object that I commit, I have to use a separate DataService
for each one?
Thanks for logging the enhancement request, as selecting which managed
object to commit would be the ideal way to handle this.
You mentioned that I cannot release a single item from a managed
collection, but is it possible to revert a single item in a managed
collection?
Thanks,
Thunder
--- In [EMAIL PROTECTED]ups.com,
"Jeff Vroom" <[EMAIL PROTECTED]>
wrote:
>
> First off, a bit about how FDMS works behind the scenes. As you change
> a property of an object, a PropertyChangedEvent is fired which tells
> FDMS of the change. A message is logged for the item indicating that
> the property is changed. If you change a second property on the object,
> we merge that property change event into to the first message. If
> autoCommit is false, when you call "commit", all pending changes
are
> sent. So if you are not changing an item, nothing is sent but if you
> have changed items A and B and the changes were logged for these items,
> there is no way to just commit the changes for item B. You can
> individually revert changes made to items however but that will roll the
> state of the item back to its state before the change.
>
>
>
> Now it is possible to release an item so that FDMS is no longer managing
> its state. At this point, FDMS will not be tracking changes to that
> item so you could call getItem on A and getItem on B, then releaseItem
> on A. Now only changes to B will be tracked. If you call fill and get
> a collection of objects, there is no way to release just a single item
> in the collection however.
>
>
>
> Your use case is an interesting one and it would not be hard for us to
> add a method which just commits the changes to a specify item so I'll
> add an enhancement for that.
>
>
>
> As for your final question, merge is used when you have set
> autoMerge=false and it will merge changes received by the server into
> the current managed set of items. As changes are received by a client
> for some set of managed items, by default they are automatically
> "merged" into the current versions of the items, but when you
turn
> autoMerge=false, they are queued up instead (the mergeRequired property
> is set in this case). At that point, you call "merge" to apply
those
> changes.
>
>
>
> Jeff
>
>
>
> ________________________________
>
> From: [EMAIL PROTECTED]ups.com
[mailto:[EMAIL PROTECTED]ups.com]
On
> Behalf Of thunderstumpgesatwork
> Sent: Tuesday, August 22, 2006 9:58 AM
> To: [EMAIL PROTECTED]ups.com
> Subject: [flexcoders] FDS Data Management quesion
>
>
>
>
> I have a question (or two) about saving/persisting/updating changes
> that have been made. I'm trying to maintain some granular level of
> control of which managed objects are saved and which are rolled back.
>
> First scenario:
>
> Assume we used dataservice.fill() to load a collection. Is it
possible
> to save only one item in the collection? How would this be done? The
> only method I saw for updating (dataservice.commit()) says it updates
> all collections managed by this data service.
>
> Second scenario:
>
> Assume we decided to query each item individually using
> dataservice.getItem(), is it possible to save one item at a
time? or
> to decide which item to save and which to roll back? Again, the
> commit() function seems to imply that all changes to all items are
> committed.
>
> And lastly, what is the difference between merge() and commit()?
>
> thanks in advance.
> Thunder
>
