Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Notifications emf vs. cdo
Notifications emf vs. cdo [message #481399] Thu, 20 August 2009 19:49 Go to next message
Florian Pirchner is currently offline Florian PirchnerFriend
Messages: 94
Registered: July 2009
Member

Hi,

i have a questing for CDONotifications. Move and remove cdoNotifications
are differing from emfNotifications.

If i am using an emfEdit moveCommand the newValue of the notification is
the moved EObject.
On commiting the cdoTransaction a CdoNotification is sent to the other
clients. But in this case, the newValue is null. I had a look at the
source code and it is not resolved there.

Maybe i have to keep attention by resolving the newValue myself.

I am using the changeSubscriptionPolicy(CDOAdapterPolicy.ALL).

Has anybody an idea, why cdo does not resolve the moved EObject and does
not put it into the new value of the notification?

Thanks in advance,
Flo
Re: Notifications emf vs. cdo [message #481404 is a reply to message #481399] Thu, 20 August 2009 20:00 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Flo,

What do you mean by "resolve"?

It's eventually just a bug in the CDODeltaNotification (probably not in
the CDOProtocol itself) that the value is not set. Simon can possibly
shed light on this...

Cheers
/Eike

----
http://thegordian.blogspot.com



Florian Pirchner schrieb:
> Hi,
>
> i have a questing for CDONotifications. Move and remove
> cdoNotifications are differing from emfNotifications.
>
> If i am using an emfEdit moveCommand the newValue of the notification
> is the moved EObject. On commiting the cdoTransaction a
> CdoNotification is sent to the other clients. But in this case, the
> newValue is null. I had a look at the source code and it is not
> resolved there.
>
> Maybe i have to keep attention by resolving the newValue myself.
>
> I am using the changeSubscriptionPolicy(CDOAdapterPolicy.ALL).
>
> Has anybody an idea, why cdo does not resolve the moved EObject and
> does not put it into the new value of the notification?
>
> Thanks in advance,
> Flo


Re: Notifications emf vs. cdo [message #481419 is a reply to message #481404] Thu, 20 August 2009 21:53 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Hi Flo and Eike,

Few features provided in EMF could have been completed in CDO and others
couldn`t...

You are right by saying that the new object for a move isn`t there...and
it was expected at the time since it is complicated to get.. but not
impossible. At the time only the position was important.

In the case of a remove.... what value are you expecting ?
CDO cannot provide all the time objects that are remove since they are
removed....

Simon


Eike Stepper wrote:

> Flo,

> What do you mean by "resolve"?

> It's eventually just a bug in the CDODeltaNotification (probably not in
> the CDOProtocol itself) that the value is not set. Simon can possibly
> shed light on this...

> Cheers
> /Eike

> ----
> http://thegordian.blogspot.com



> Florian Pirchner schrieb:
>> Hi,
>>
>> i have a questing for CDONotifications. Move and remove
>> cdoNotifications are differing from emfNotifications.
>>
>> If i am using an emfEdit moveCommand the newValue of the notification
>> is the moved EObject. On commiting the cdoTransaction a
>> CdoNotification is sent to the other clients. But in this case, the
>> newValue is null. I had a look at the source code and it is not
>> resolved there.
>>
>> Maybe i have to keep attention by resolving the newValue myself.
>>
>> I am using the changeSubscriptionPolicy(CDOAdapterPolicy.ALL).
>>
>> Has anybody an idea, why cdo does not resolve the moved EObject and
>> does not put it into the new value of the notification?
>>
>> Thanks in advance,
>> Flo
Re: Notifications emf vs. cdo [message #481447 is a reply to message #481419] Fri, 21 August 2009 05:45 Go to previous messageGo to next message
Florian Pirchner is currently offline Florian PirchnerFriend
Messages: 94
Registered: July 2009
Member

Hi simon, hi eike,

i think that it not so easy to determine the influenced objects for some
events in cdo, because they do not exist anymore, when cdo creates the
change notification. Specially for removes.

In the case of a remove notfication i would expect the removed eObject in
the oldValue of the notification and the container of the removed object
as the notifier.

Do i have to use the revision to get the removed object? I think so. What
do you think?

For move operations i have already resolved the oldObject myself, because
it is still existing inside the same parent container. The notifier,
feature and position are enough to get the influenced object.

For my purpose it is absoultly important to have access to the oldObjects.
Redview uses these informations to change the swt ui by passing them to
the ui controllers.

It would be really great, if you can point me a way how to access the
removed object. I am not sure what is the best practice in cdo? Currently
the revision seams to be best way of doing so.

Lots of Thanks, Flo
Re: Notifications emf vs. cdo [message #481450 is a reply to message #481447] Fri, 21 August 2009 06:10 Go to previous messageGo to next message
Florian Pirchner is currently offline Florian PirchnerFriend
Messages: 94
Registered: July 2009
Member

Hi again,

i was talking about audit and not revision.

Sorry...

Flo
Re: Notifications emf vs. cdo [message #481516 is a reply to message #481447] Fri, 21 August 2009 11:13 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
First you need to have access to older version so your audit should be
turn to true.

In this case, you could open a AuditView at a specific time.
session.openAudit(....).

To know which time could be tricky. I think we could add more info to make
your life simple. (You can open a bugzilla for that- To add timestamp of
the transaction into the notifications)!!

For now you can...
- Access the old revision with the
revisionManager.getRevision(revisionDelta.getID,
revisionDelta.getVersion()).
- Use revision.getTimestamp() to retrieved the right timestamp to use for
the openAudit(revision.getTimestamp()).
- Access the old object audit.getObject(id);


Simon
Re: Notifications emf vs. cdo [message #481541 is a reply to message #481516] Fri, 21 August 2009 13:25 Go to previous messageGo to next message
Florian Pirchner is currently offline Florian PirchnerFriend
Messages: 94
Registered: July 2009
Member

Thanks, listens good!

Greetings, Flo
Re: Notifications emf vs. cdo [message #481646 is a reply to message #481516] Sat, 22 August 2009 08:33 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Simon Mc Duff schrieb:
> For now you can...
> - Access the old revision with the
> revisionManager.getRevision(revisionDelta.getID,
> revisionDelta.getVersion()).
> - Use revision.getTimestamp() to retrieved the right timestamp to use
> for the openAudit(revision.getTimestamp()).
> - Access the old object audit.getObject(id);
Maybe you can use this as an alternative:

org.eclipse.emf.cdo.util.CDOUtil.getRevisionByVersion(CDOObj ect, int)

If you need a respective getRevisionByTime() method in CDOUtil, please
file a bugzilla ;-)

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Previous Topic:Tools for undertanding and documenting code structure
Next Topic:Add and remove commands does not get overridden for one of two defined children
Goto Forum:
  


Current Time: Fri Mar 29 14:52:46 GMT 2024

Powered by FUDForum. Page generated in 0.03369 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top