|
| Re: [Teneo/Hibernate] Resource saving problems when moving to Eclipse 3.4 [message #420522 is a reply to message #420441] |
Tue, 01 July 2008 22:33   |
 Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Manfred,
Normally removal from a resource results in deletion. I would say that the model resource should be
loaded and that referenced objects should not be added to the model resource. This is the default
behavior. Do you pass the StoreResource.LOAD_STRATEGY_PARAM parameter to the modelresource? See here:
http://www.elver.org/hibernate/hibernateresources.html#Load+ of+referenced+Objects
You can check if objects are added to a resource by setting a breakpoint in the attachedhelper and
detachedhelper methods.
Can you try the latest build (today)?
gr. Martin
Manfred Hahn wrote:
> Hi Martin,
>
> I have moved to Eclipse 3.4 :-), but now I have a problem with saving
> the model to my Database :-<
> I'm working with GMF.
> I didn't change anything in the source and I am using the same hibernate
> mapping file.
> In my test I only open (load) my model and change the position of a
> diagram node object just to have the possibility to save it again.
> In Eclipse 3.3 everything is fine, in Eclipse 3.4 I get the following
> exception:
>
> org.hibernate.ObjectDeletedException: deleted object would be re-saved
> by cascade (remove deleted object from associations):
> [BenutzerFrage#ff8080811ac8a31c011ac8a983c00001]
> at org.hibernate.impl.SessionImpl.forceFlush(SessionImpl.java:1 014)
> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.ent ityIsTransient(DefaultSaveOrUpdateEventListener.java:165)
>
> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.per formSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
>
> at
> org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onS aveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
>
> at
> org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl. java:507)
> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java :499)
> at
> org.hibernate.engine.CascadingAction$5.cascade(CascadingActi on.java:218)
> at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :216)
> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
> at
> org.hibernate.engine.Cascade.cascadeCollectionElements(Casca de.java:296)
> at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java: 242)
> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java :219)
> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:16 9)
> at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
> at
> org.hibernate.event.def.AbstractFlushingEventListener.cascad eOnFlush(AbstractFlushingEventListener.java:131)
>
> at
> org.hibernate.event.def.AbstractFlushingEventListener.prepar eEntityFlushes(AbstractFlushingEventListener.java:122)
>
> at
> org.hibernate.event.def.AbstractFlushingEventListener.flushE verythingToExecutions(AbstractFlushingEventListener.java:65)
>
> at
> org.hibernate.event.def.DefaultFlushEventListener.onFlush(De faultFlushEventListener.java:26)
>
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
> at
> org.eclipse.emf.teneo.hibernate.HbSessionWrapper.flush(HbSes sionWrapper.java:161)
>
>
> I did not delete any object! I only moved a graphical node! The object
> mentioned in the exception has not been changed anyway.
>
> There seems to be the following reason in the behaviour of Eclipse 3.4:
>
> I work with three resources:
> 1. the diagram resource, which I store in xml notation (but inside of a
> blob field of the database).
> 2. the model resource. This is the model I edit in the gmf graphical
> editor. It is in the database via teneo/hibernate.
> 3. a configuration resource. This is a resource that is used by more
> than one model resource. The model resource has references to objects of
> the configuration resource (but of cause no containments). The
> configuration resource is also in the database via teneo/hibernate.
>
> When I load the diagram resource, the model resource is loaded
> automatically by the framework. After the load my ResourceSet contains
> these two top resources: the diagram resource and the model resource.
> The configuration resource is loaded indirectly by loading the model
> resource. This resource was not a top level resource in the ResourceSet.
>
> I found out that this behaviour had some restrictions with the
> CommandStack and the UNDO/REDO operations. The ChangeRecorder works on
> the ResourceSet and did not record the changes in the configuration
> resource. For this reason I changed the load process and did an explicit
> load on the configuration resource after loading the model resource. Now
> the configuration resource is also a top level resource in the
> ResourceSet, and all changes in the configuration resource are recorded
> by the ChangeRecorder and can be undone and redone. All this loading is
> done with one EditingDomain and one SessionController.
>
> My imagination was that every object from the configuration resource
> that has previously been loaded indirectly by the model resource would
> be removed from the model resource and put into the configuration
> resource, but without any object deletion.
>
> With Eclipse 3.3 my imagination was right. Everything worked as expected.
>
> But with Eclipse 3.4 something was changed. The object in the exception
> message is one that is contained by the configuration resource and
> referenced by the model resource. The hibernate diagnostic in the
> prepareEntityFlushes() is that this object had been deleted
> (EntityState). There is an connection to loading of the configuration
> resource. The proof is: I removed my explicit loading of the
> configuration resource. Then the saving flush has no more exceptions.
> But again there is no undo/redo operation on the configuration resource.
>
> In fact this seems to be a change in the handling of resources in the
> ResourceSet.
>
> So my question is: What do I have to do to have a clean save flush AND
> to have the undo/redo-Operations for the configuration resource in the
> new environment? And what has been changed that my previously correct
> working solution does not work any more?
>
> Do you have any advice for me?
>
> gr. Manfred
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
|
| Re: [Teneo/Hibernate] Resource saving problems when moving to Eclipse 3.4 [message #420613 is a reply to message #420532] |
Thu, 03 July 2008 19:47 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Manfred,
This seems like a bug to me. There are two solutions I think, change this add-to-resource behavior
and/or allow moving of objects from one resource to another without deleting them.
To try the second approach, if you have time then you can try to override the HibernateResource and
then the saveResource method:
protected void saveResource(Map<?, ?> options) {
// correct the removed objects list
final ArrayList<Object> notRemove = new ArrayList<Object>();
for (Object obj : removedEObjects) {
final InternalEObject eobj = (InternalEObject) obj;
if (eobj.eResource() != null && eobj.eResource() != this) {
notRemove.add(eobj);
}
}
removedEObjects.removeAll(notRemove);
super.saveResource(Map<?, ?> options);
}
Let me know if this works for you.
gr. Martin
Manfred Hahn wrote:
> Hi Martin,
>
> thanks for your hints.
>
> I use the default of the LOAD_STRATEGIE_PARAM, so in my szenario I
> expect that the configuration resource is not automatically added to the
> model resource. But it is!
>
> I debugged the StoreResource.attachedHelper(). The root object of the
> configuration resource is added to the model resource directly after
> adding the root object of the model resource itself. The configuration
> root is linked with a non containment reference to the model root.
>
> In the method StoreResource.addToContentOrAttach() is the following code:
> if (loadStrategy.compareTo(ADD_TO_CONTENTS) == 0) {
> ....
> } else if (eReference.isContainment()) {
> ....
> } else {
> // this is not the nicest solution but it prevents dangling
> references
> // when objects are not added explicitly to a resource
> setEResource(eObject, false);
> attached(eObject);
> }
>
> so with the last else part objects that are referenced but not contained
> are added to the resource also. (The setEResource() sets the eObject to
> be directly contained by the resource). This is different from the
> statement in the documentation to the StoreResource.SET_ERESORUCE value
> ("Object references through non-containment relations are not added to
> the contents of a resource").
>
> Is this a bug? How should the situation be handled?
>
> NB: I'm not able to debug the teneo code in eclipse 3.4. The statement
> says "Source not found. The JAR of this class belongs to the container
> 'Plug-in Dependencies' which does not allow modifications to source
> attachments on its entries". This behaviour is shown on the complete
> org.eclipse.emf.teneo_1.0.0.v200807010416.jar. In contrast to this is
> the source of the org.eclipse.emf.teneo.hibernate.jar readable. My
> analysis above is from an older teneo version, but I've looked into the
> new source jar (with another tool) and saw that the code did not change.
> Do I have to change a preference to read the source in Eclipse? Or is
> this a thing you have to change when you build the jar? I've installed
> the latest version at your advice.
>
> gr. Manfred
>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
|
| Re: [Teneo/Hibernate] Resource saving problems when moving to Eclipse 3.4 [message #420631 is a reply to message #420623] |
Fri, 04 July 2008 13:29 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Manfred,
Yes it was to get a feel for the solution. Btw, extending/overwriting HibernateResource is no
problem and manipulating the registry maps is also fine.
After some more thought I think the dangling reference issue is more something which should have
been solved by the user by choosing the other load strategy. So this needs to be changed.
What you can try (until I fix this) is overriding the addToContentOrAttach and use this one
(commented out two lines in the else) in your overriden resource:
public void addToContentOrAttach(InternalEObject eObject, EReference eReference) {
final boolean oldLoading = isLoading();
try {
if (loadStrategy.compareTo(ADD_TO_CONTENTS) == 0) {
if (eObject.eResource() != null && eObject.eResource() != this) {
return;
}
// always add to the resource, this will change
// the contents of the resource
addUsingContainmentStructure(eObject);
} else if (eReference.isContainment()) {
// if resolve proxies then it is allowed to have child objects in other
// resources
if (eReference.isResolveProxies() && eObject.eResource() != null && eObject.eResource() != this) {
return;
}
// only add if contained, just add to the loaded eobjects lists
assert (eObject.eContainer().eResource() == this);
attached(eObject);
} else {
// this is not the nicest solution but it prevents dangling references
// when objects are not added explicitly to a resource
//setEResource(eObject, false);
//attached(eObject);
}
} finally {
setIsLoading(oldLoading);
}
}
Can you let me know if this works?
gr. Martin
Manfred Hahn wrote:
> Hi Martin,
>
> yes, your solution works. But it seems like healing the symptom and not
> the cause. And the overwriting of HibernateResource is somewhat tricky,
> since I had to manipulate the registry maps to connect the hibernate
> protocol to my new MyHibernateResourceFactory... (Or is there an easy
> way I did not see?)
>
> I'd prefere the first solution. But I can not imagine what consequences
> the changed behaviour would have, looking at your comment about the
> dangling references.
>
> NB: I now can read the teneo source after an uninstall of the previous
> version.
>
> gr. Manfred
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03932 seconds
] 
Search
Help
Register
Login
Home
