Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community Forums[Solved]Handling subclasses of Entities (Cross Bundle Workaround)
https://www.eclipse.org/forums/index.php/mv/msg/470445/1034539/#msg_1034539
We have a main class. We call it Form.
Form is a base class where we begin most of our implementations for our project. Subclasses of form are not in the same bundle as Form.
Our current strategy is when we persist/load/delete/update our database on a derived class Form, we create new instances of the base class (clone) when persisting or updating and we copy when an update is called.
We are looking for a way to minimize memory requirements on our persist and update calls. Having to clone ( copies also do clones on referenced objects) extensively large entities for persisting and updating is very memory and computational intensive.
With the current release of 1.1 Gemini, I am looking for a way to create subclasses of an entity and to treat it as it's base class. Right now if I try to persist a derived class out of its bundle, it will state that the derived class entity is not within the entity table and therefore can not be manipulated.
Is there some kind of annotation that forces gemini to treat subclasses as their base types? If so, I would like to also figure out if this can be handled outside of the base class's bundle such that I do not have to add the derived type to the persistence.xml file.
TL;DR: Treat out of bundle, derived types as base types when performing CRUD operations with gemini and to not add the derived types to the xml file.]]>Scott Hull2013-04-05T15:09:52-00:00Re: Handling subclasses of Entities (Cross bundle work around)
https://www.eclipse.org/forums/index.php/mv/msg/470445/1034544/#msg_1034544
Scott Hull2013-04-05T15:14:43-00:00Re: Handling subclasses of Entities (Cross bundle work around)
https://www.eclipse.org/forums/index.php/mv/msg/470445/1036773/#msg_1036773
There is no way to make Gemini see the derived class and treat it as something other than a derived class. EclipseLink will need to go up the class hierarchy to see if there are mapped superclasses, etc, above it. If you are looking to lower your memory footprint, though, I don't think trying to fake out the superclass would be the right path to follow in any case.
You might want to look at what attributes of the Form can be made lazy vs eager so that they don't even get loaded. (Since you were willing to vaporize the superclass out of existence then you must not need the inherited state.) Look at ways to reduce the objects that even get loaded rather than trying to hack around the Java model.
-Mike]]>Michael Keith2013-04-08T19:51:06-00:00Re: Handling subclasses of Entities (Cross bundle work around)
https://www.eclipse.org/forums/index.php/mv/msg/470445/1037503/#msg_1037503
Thanks for your reply.
>There is no way to make Gemini see the derived class and treat it as something other than a derived class.
Yeah, I thought that was the case. I was trying to take a theoretical approach to it to see if there was a probable solution at hand.
We need all the data that is persisted on the Form, but it looks like a shallow copy routine would be the better solution when applying CRUD operations on our derived types.
The derived classes's private data was considered local "state" data anyhow. I was trying to find a different solution that a shallow copy.