I've finally gotten around to working more on this and ran into another
question...
In Rhett's suggestion he writes:
"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.)"
This is the approach I have pursued. I now have a MyApplication object
that contains 11 other objects each with its own respective properties
and getter/setters. The MyApplication object still has a few properties
and then all of the original getter/setter methods that now reference
the corresponding getter/setter methods in the component objects.
My question is with #4 above. When I look at the examples in the castor
source distribution, there are no examples of the "depends" relationship
in the mapping file. I found an IBM web site with a tutorial on castor
JDO and it had a different example mapping file for ProductDetail that
did have the depends... Anyhow...
What I need to do now is tell castor that the MyApplication object is a
composite of smaller objects and to populate each of them when it
loads/saves the parent. So it seems like I want to tell castor that
MyApplication depends on a bunch of smaller objects, not the other way
around, so I'm confused. How does castor link them? Here's what I
have:
<class name="org.alt60m.hr.si.model.MyApplication" access="shared"
key-generator="UUID" identity="applicationID">
<map-to table="hr_si_Application" />
<field name="applicationID" type="string">
<sql type="varchar" name="applicationID" />
<bind-xml name="applicationID" />
</field>
<field ... />
</class>
<class name="org.alt60m.hr.si.model.App_MinExperience"
depends="org.alt60m.hr.si.model.MyApplication"
access="shared" key-generator="UUID"
identity="id">
<map-to table="hr_si_MinExperience" />
<field name="id" type="string">
<sql type="varchar" name="id" />
<bind-xml name="id" />
</field>
<field ... />
</class>
<class name="org.alt60m.hr.si.model.App_MinInterests"
depends="org.alt60m.hr.si.model.MyApplication"
access="shared" key-generator="UUID"
identity="id">
<map-to table="hr_si_MinInterests" />
<field name="id" type="string">
<sql type="varchar" name="id" />
<bind-xml name="id" />
</field>
<field ... />
</class>
Sure appreciate the help... thanks,
Ken.
-----Original Message-----
From: Rhett Sutphin [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 20, 2002 6:00 PM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] relational inheritance question
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.
>
> 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.
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.
> So my question is: does relational inheritance do this for me?
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.
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
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
