| [Solved]Handling subclasses of Entities (Cross Bundle Workaround) [message #1034539] |
Fri, 05 April 2013 15:09  |
 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 16:43] Report message to a moderator |
|
|
|
|
| Re: Handling subclasses of Entities (Cross bundle work around) [message #1037503 is a reply to message #1034539] |
Tue, 09 April 2013 16:35  |
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 16:44] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.02643 seconds
] 
Search
Help
Register
Login
Home
