Eclipse Community Forums: EMF » [cdo] which class is responsible for deleting a model element

Home » Modeling » EMF » [cdo] which class is responsible for deleting a model element

[cdo] which class is responsible for deleting a model element [message #1097150]

Thu, 29 August 2013 05:49

Eclipse User

I am very new to CDO. I shifted to CDO due to some drawbacks in EMF-STORE. Coming to the point i created a ecore model then generated a genmodel[cdo native] and then generated edit and editor codes. Now I created a CDO server and running a CDO client as well. I am able to add model elements and and deleting as well. Some model elements which seeks for a reference model element, we have a drop down menu which shows all the elements to set a reference. Now i also created a Junit class to access CDO. I am able to add, setting references to model from Junit class also like UI. But the problem is following-

1)let say we have two model elements A and B both have a attribute ID but A has a reference to B

A - ID , reference to B
B - ID

now if I delete B from UI ( right click on B and then delete) then this automatically setting reference field in A to null which is correct behavior.
But if I delete B from Junit class using resource.getContents().remove(B); where resource is a object of CDOResource then its creating problem. like its not setting reference to null which is causing the problem of Dangling reference. Now this is creating some serious issue like i wont be able to change the resource to some other model element neither from UI nor from Junit class.In UI its not showing any drop down option in reference field. And now i wont be able to delete A from UI or Junit class because of the dangling issue. So my question is that Which API should I use to delete a model element from Junit class which the delete from the UI might be using so that this problem of dangling reference should not happen.

2) I am using MYSQL as back end database. And i guess MYSQL support all the features ( which includes auditing view). But i m not able to get the audit view. What config changes should i make in configuration file of the server to make the audit view working

3) Is it possible to make queries based on reference. For example let say we want to search for all the model elements which are referring to a model element let say B.

Re: [cdo] which class is responsible for deleting a model element [message #1097195 is a reply to message #1097150]

Thu, 29 August 2013 07:04

Eclipse User

Am 29.08.2013 11:49, schrieb saurav singh:
> I am very new to CDO. I shifted to CDO due to some drawbacks in EMF-STORE. Coming to the point i created a ecore model
> then generated a genmodel[cdo native] and then generated edit and editor codes. Now I created a CDO server and running
> a CDO client as well. I am able to add model elements and and deleting as well. Some model elements which seeks for a
> reference model element, we have a drop down menu which shows all the elements to set a reference. Now i also created
> a Junit class to access CDO. I am able to add, setting references to model from Junit class also like UI. But the
> problem is following-
>
> 1)let say we have two model elements A and B both have a attribute ID but A has a reference to B
>
> A - ID , reference to B
> B - ID
>
> now if I delete B from UI ( right click on B and then delete) then this automatically setting reference field in A to
> null
Yes, I'm not an EMF Edit expert but I think org.eclipse.emf.edit.command.RemoveCommand does that.

> which is correct behavior.
Correct according to your requirements ;-)

> But if I delete B from Junit class using resource.getContents().remove(B); where resource is a object of CDOResource
> then its creating problem. like its not setting reference to null which is causing the problem of Dangling reference.
That's not a CDO-specific behaviour. A "normal" EMF model behaves in exactly the same way unless you use EcoreUtil.delete().

Please note that EcoreUtil.delete() employs a UsageCrossReferencer which can be highly inadequate in the context of huge
models. CDO offers API such as CDOView.queryXRefs() that allows you to find incoming references without loading the
entire model into the client.

> Now this is creating some serious issue like i wont be able to change the resource to some other model element neither
> from UI nor from Junit class.In UI its not showing any drop down option in reference field. And now i wont be able to
> delete A from UI or Junit class because of the dangling issue. So my question is that Which API should I use to delete
> a model element from Junit class which the delete from the UI might be using so that this problem of dangling
> reference should not happen.
>
> 2) I am using MYSQL as back end database. And i guess MYSQL support all the features ( which includes auditing view).
Yes, the set of available CDO functionality is not impacted by the JDBC driver choice.

> But i m not able to get the audit view. What config changes should i make in configuration file of the server to make
> the audit view working
Your cdo-server.xml must contain this line *before* you start the server for the first time:

<property name="supportingAudits" value="true"/>

> 3) Is it possible to make queries based on reference. For example let say we want to search for all the model elements
> which are referring to a model element let say B.
See above ;-)

And then there's also support for OCL queries and native SQL queries (the latter are a little tricky in combination with
auditing!).

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: [cdo] which class is responsible for deleting a model element [message #1097196 is a reply to message #1097195]

Thu, 29 August 2013 07:05

Eclipse User

Am 29.08.2013 13:04, schrieb Eike Stepper:
> Am 29.08.2013 11:49, schrieb saurav singh:
>>
>> now if I delete B from UI ( right click on B and then delete) then this automatically setting reference field in A to
>> null
> Yes, I'm not an EMF Edit expert but I think org.eclipse.emf.edit.command.RemoveCommand does that.
Correction: org.eclipse.emf.edit.command.DeleteCommand

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: [cdo] which class is responsible for deleting a model element [message #1097316 is a reply to message #1097195]

Thu, 29 August 2013 10:32

Eclipse User

On 29-08-13 13:04, Eike Stepper wrote:
> Am 29.08.2013 11:49, schrieb saurav singh:
>> I am very new to CDO. I shifted to CDO due to some drawbacks in
>> EMF-STORE. Coming to the point i created a ecore model then generated
>> a genmodel[cdo native] and then generated edit and editor codes. Now I
>> created a CDO server and running a CDO client as well. I am able to
>> add model elements and and deleting as well. Some model elements which
>> seeks for a reference model element, we have a drop down menu which
>> shows all the elements to set a reference. Now i also created a Junit
>> class to access CDO. I am able to add, setting references to model
>> from Junit class also like UI. But the problem is following-
>>
>> 1)let say we have two model elements A and B both have a attribute ID
>> but A has a reference to B
>>
>> A - ID , reference to B
>> B - ID
>>
>> now if I delete B from UI ( right click on B and then delete) then
>> this automatically setting reference field in A to null
> Yes, I'm not an EMF Edit expert but I think
> org.eclipse.emf.edit.command.RemoveCommand does that.
>
>> which is correct behavior.
> Correct according to your requirements ;-)
>
>> But if I delete B from Junit class using
>> resource.getContents().remove(B); where resource is a object of
>> CDOResource then its creating problem. like its not setting reference
>> to null which is causing the problem of Dangling reference.
> That's not a CDO-specific behaviour. A "normal" EMF model behaves in
> exactly the same way unless you use EcoreUtil.delete().
>
> Please note that EcoreUtil.delete() employs a UsageCrossReferencer which
> can be highly inadequate in the context of huge models. CDO offers API
> such as CDOView.queryXRefs() that allows you to find incoming references
> without loading the entire model into the client.
>
I have made a specialized implementation which does exactly this:

https://github.com/dzonekl/netxstudio/blob/topic_kepler_build/screens/com.netxforge.netxstudio.screens.editing/src/com/netxforge/netxstudio/screens/editing/actions/WarningDeleteCommand.java

>> Now this is creating some serious issue like i wont be able to change
>> the resource to some other model element neither from UI nor from
>> Junit class.In UI its not showing any drop down option in reference
>> field. And now i wont be able to delete A from UI or Junit class
>> because of the dangling issue. So my question is that Which API should
>> I use to delete a model element from Junit class which the delete from
>> the UI might be using so that this problem of dangling reference
>> should not happen.
>>
You can use the EMF edit API in you unit class, just like the UI.

c = DeleteCommand.create(.....)
EditingDomain d ..
d.getCommandStack().execute(c)

>> 2) I am using MYSQL as back end database. And i guess MYSQL support
>> all the features ( which includes auditing view).
> Yes, the set of available CDO functionality is not impacted by the JDBC
> driver choice.
>
>> But i m not able to get the audit view. What config changes should i
>> make in configuration file of the server to make the audit view working
> Your cdo-server.xml must contain this line *before* you start the server
> for the first time:
>
> <property name="supportingAudits" value="true"/>
>
>> 3) Is it possible to make queries based on reference. For example let
>> say we want to search for all the model elements which are referring
>> to a model element let say B.
> See above ;-)
>
> And then there's also support for OCL queries and native SQL queries
> (the latter are a little tricky in combination with auditing!).
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>

Re: [cdo] which class is responsible for deleting a model element [message #1097745 is a reply to message #1097316]

Fri, 30 August 2013 01:38

Eclipse User

Thanks Eike for your reply, it really helped.

> 3) Is it possible to make queries based on reference. For example let say we want to search for all the model elements
> which are referring to a model element let say B.

Is it possible to make SQL queries based on references like SELECT * FROM student WHERE student.address.place LIKE delhi
where student is model element which has a name associated and a reference to a address &
address is another model element type with a field place

Re: [cdo] which class is responsible for deleting a model element [message #1097949 is a reply to message #1097745]

Fri, 30 August 2013 07:32

Eclipse User

Am 30.08.2013 07:38, schrieb saurav singh:
> Thanks Eike for your reply, it really helped.
You're welcome.

>
>> 3) Is it possible to make queries based on reference. For example let say we want to search for all the model
>> elements which are referring to a model element let say B.
>
> Is it possible to make SQL queries based on references like SELECT * FROM student WHERE student.address.place LIKE delhi
> where student is model element which has a name associated and a reference to a address &
> address is another model element type with a field place
It's possible but not in the way you're suggesting. The challenge with SQL queries is that the used names must refer to
tables or columns, not EClasses or EStructuralFeatures. Currently only the OCLQueryHandler and the HQLQueryHandler
(provided by the HibernateStore) support query definitions based on model-level names.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Previous Topic:	No Notification send in Pde Test while executing Recoeding Command
Next Topic:	[Teneo] Teneo Mapping XML file and Named Native Queries

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 19 22:50:58 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter