Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Gemini » [Solved]Handling subclasses of Entities (Cross Bundle Workaround)(Looking for a better, more efficient way to work around subclassed entities that are not in the same bundle)
[Solved]Handling subclasses of Entities (Cross Bundle Workaround) [message #1034539] Fri, 05 April 2013 11:09 Go to next message
Scott Hull is currently offline Scott Hull
Messages: 32
Registered: July 2012
Member
Here is the situation.

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.

[Updated on: Tue, 09 April 2013 12:43]

Report message to a moderator

Re: Handling subclasses of Entities (Cross bundle work around) [message #1034544 is a reply to message #1034539] Fri, 05 April 2013 11:14 Go to previous messageGo to next message
Scott Hull is currently offline Scott Hull
Messages: 32
Registered: July 2012
Member
Please note that I understand this will not be possible with loading operations and that a copy call will have to be used on the derived class in order to load all of the pieces accordingly.

[Updated on: Fri, 05 April 2013 11:15]

Report message to a moderator

Re: Handling subclasses of Entities (Cross bundle work around) [message #1036773 is a reply to message #1034539] Mon, 08 April 2013 15:51 Go to previous messageGo to next message
Mike Keith is currently offline Mike Keith
Messages: 211
Registered: July 2009
Senior Member
Hi Scott,

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
Re: Handling subclasses of Entities (Cross bundle work around) [message #1037503 is a reply to message #1034539] Tue, 09 April 2013 12:35 Go to previous message
Scott Hull is currently offline Scott Hull
Messages: 32
Registered: July 2012
Member
Mike,

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.

Marking this as solved.

Thanks again!
Scott






[Updated on: Tue, 09 April 2013 12:44]

Report message to a moderator

Previous Topic:Using JPA without publishing the persistence unit with Gemini JPA
Next Topic:Invalid registry object in "org.eclipse.ui.workbench", Gemini JPA/DBAccess
Goto Forum:
  


Current Time: Thu Aug 28 09:23:10 EDT 2014

Powered by FUDForum. Page generated in 0.11076 seconds