Home » Modeling » EMF » [CDO] CDOAdapter vs CDOViewInvalidationEvent
|
Re: [CDO] CDOAdapter vs CDOViewInvalidationEvent [message #1000781 is a reply to message #1000744] |
Tue, 15 January 2013 12:28 |
|
Am 15.01.2013 12:21, schrieb Christophe Bouhier:
> Hello,
> In the title I suggest that CDOAdapter and CDOViewInvalidationEvent compete, which is what I would like to be
> confirmed. Nowdays, when I have to deal with invalidations I do:
> 1. turn on passive updates. 2. Register an IListener on a CDOView , and dispatch according to the event, i.e. an
> CDOViewInvalidationEvent would be used to call refresh() on a viewer. 3. I also call
> view.options().addChangeSubscriptionPolicy(CDOAdapterPolicy.CDO); which would be used when adding a CDOAdapter to an
> object to be observed.
> Question: If that same object is data-bound to a JFace viewer, any notification would also be reflected on the viewer.
> Is this statement correct?
> I guess, I am asking how to use a CDOAdapter in combination with JFace databinding.
The effects of CDOViewInvalidationEvent and EMF adapter notification are very similar. They originate from the same
doInvalidate() method in CDOViewImpl (i.e. they don't compete for exclusive usage):
fireInvalidationEvent(lastUpdateTime, Collections.unmodifiableMap(revisionDeltas),
Collections.unmodifiableSet(detachedObjects));
// First handle the conflicts, if any.
if (conflicts != null)
{
handleConflicts(conflicts, deltas);
}
// Then send the notifications. The deltas could have been modified by the conflict resolvers.
if (!deltas.isEmpty() || !detachedObjects.isEmpty())
{
sendDeltaNotifications(deltas, detachedObjects, oldRevisions);
}
You see that adapters are only notified if deltas are available while the invalidation event (as the name implies) is
also emitted if only the IDs of the changed objects are available. There are two ways to request that the server sends
deltas in addition to the object IDs:
1) session.options().setPassiveUpdateMode(PassiveUpdateMode.CHANGES);
2) view.options().addChangeSubscriptionPolicy(CDOAdapterPolicy.ALL);
Does that help?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Re: [CDO] CDOAdapter vs CDOViewInvalidationEvent [message #1000804 is a reply to message #1000791] |
Tue, 15 January 2013 13:00 |
|
Am 15.01.2013 13:46, schrieb Christophe Bouhier:
> Yes this helps! So there is a relation between the passiveUpdateMode and which subscriptions are delivered. Still I am
> not sure what the purpose of CDOAdapter is, if the policy is CDOAdapterPolicy.CDO.
It's just a convenient way to limit subscriptions to specific adapters, those that implement CDOAdapter.
> If the passive update mode is CHANGES, this means that I will receive the delta's by a listener which processes an
> InvalidationEvent.
And all adapters are also notified! The passive update mode was introduced together with the offline and fail-over
replication where a client (the repository synchronizer) really needs all deltas from all objects at all times,
unconditionally.
> So basically all information is in the delta, why would I need to add a CDOAdapter to the object?
You don't have to. That depends on your change subscription policy.
> Is it that both approaches are interchangeable, and do more or less the same thing?
Yes, more or less.
> So why are there two ways? (If my observation is correct..)
Their characteristics can be very different, especially for large and heavily modified repositories, where you only work
with few local objects.
And there are historical reasons. Adapter notification as such is a little newer than the event mechansim.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | | |
Re: [CDO] CDOAdapter vs CDOViewInvalidationEvent [message #1006606 is a reply to message #1006571] |
Fri, 01 February 2013 07:03 |
|
Am 31.01.2013 21:15, schrieb Christophe Bouhier:
> Eike,
> I tried the CDOLazyContentAdapter today. It seems it only registers adapters in an CDOObjectHandler, when the object
> is of type Resource.
Why do you think this?
> (Which seems to be the purpose, as it is used only as an adapter for CDOModificationTracking of a CDO Resource).
No. If it would only exist to be an implementation detail of modification tracking, we'd probably have made it internal.
> So this code, will add adapters to newly added root target, which has to be a Resource. Is this a correct observation?
No, I don't think so.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> protected void setTarget(EObject target)
> {
> if (isConnectedObject(target))
> {
> if (adaptedRoot == null)
> {
> adaptedRoot = new WeakReference<CDOObject>(CDOUtil.getCDOObject(target));
> }
>
> basicSetTarget(target);
> if (target instanceof Resource)
> {
> addCleanObjectHandler(target);
> }
> }
> else
> {
> super.setTarget(target);
> }
> }
>
> merci Christophe
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Re: [CDO] CDOAdapter vs CDOViewInvalidationEvent [message #1006625 is a reply to message #1006619] |
Fri, 01 February 2013 09:06 |
|
Am 01.02.2013 09:38, schrieb Christophe Bouhier:
> I tried it, when I pass a non Resource object, this code:
>
> if (target instanceof Resource){
> addCleanObjectHandler(target);
> }
>
> prevents it from adding the objectHandler, which will do the actual adding of the already loaded objects in the view.
I see. I'm not sure why Vik added this guard, but you're right, CDO itself only uses the adapter with resource roots:
org.eclipse.emf.cdo.util.CDOLazyContentAdapter
org.eclipse.emf.cdo.util.CDOModificationTrackingAdapter.CDOModificationTrackingAdapter(CDOResource)
org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_247141_Test.testBehaviourOnUncommittedObjects()
org.eclipse.emf.cdo.tests.bugzilla.Bugzilla_247141_Test.testContentAdapterBehaviour()
> I will further test it, and might submit a bug, test and patch for it.
I agree that this should be tested and fixed eventually. The chance that this happens soon is bigger with a patch ;-)
Thanks!
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Goto Forum:
Current Time: Thu Sep 26 12:35:15 GMT 2024
Powered by FUDForum. Page generated in 0.04759 seconds
|