On Friday, December 20, 2002, at 01:20 PM, Ken Burcham wrote:
�I noticed on the tips and tricks page (http://castor.exolab.org/tips-tricks.html) a reference to relational inheritance that might help me, but I wanted to ask specifically.I don't think you can do this with castor without changing your object model. However, the changes could still be transparent to your app, so long as you can insert objects into the inheritance hierarchy above MyApplication.
Details:
The situation is we have an object called "MyApplication" that contains a very large number of String properties each representing a question (er, answer rather) and maps to MyTable.�
What I'd like to do (besides breaking up MyApplication into multiple objects, which is really quite impractical given rewrite that would be necessary) is tell castor to simply save these group of fields to table MyApplicationA and these group of fields to MyApplicationB and these others to MyApplicationC. �All would have the same key, and would be properly aggregated into one MyApplication java object, and thus transparent to my application.
Yes. But, AFAIK, you can't have relational inheritance without java class inheritance. With that caveat, here's how you might be able to do it.So my question is: does relational inheritance do this for me?
1) Break the "very large number" of String properties into groups that you are confident will fit in a single row.
2) Create a hierarchy of objects, each one having the concrete implementation (fields and accessor/mutators) of one of these groups:
[Current parent of MyApplication]
|
MyApplicationGroup1
|
MyApplicationGroup2
.
.
.
MyApplicationGroupN
|
MyApplication
3) Map each of these group objects using the castor extends relationship.
That grossly perverts the concept of inheritance, but what do you expect with legacy code?
A more tasteful approach would be:
1) Break up the fields into groups as above.
2) Create java classes for each of these groups.
3) Rewrite MyApplication so it contains one instance of each group. Reimplement its accessor/mutator methods to transparently deal with the fields in these group classes. (This gives you transparency with other code which currently uses MyApplication.)
4) Map each group for castor using a 1:1 depends relationship to MyApplication. Don't map anything for MyApplication except for its id. (This gives you single-operation loads and stores with JDO.)
Depending on how the fields fall, you might even be able to create the groups such that they match up with the pages. Then, you could get rid of the depends relationship and load/store just the fields for a given page when that page is accessed. The downside to that is that you would need to manually load every group whenever you wanted to use the complete MyApplication object.
In summary, I think the thing you need to do is reimplement MyApplication as a proxy over some set of objects. If you can't do that (i.e., I misinterpreted what you meant when you said you couldn't "break up MyApplication into multiple objects"), I don't know of a way to do what you want with castor.
HTH,
Rhett
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
