hi bob
In this example there is a m:n relationship between JobGroup's &
JobContext's. The JobGroup class has a collection of JobContext's, but the
JobContext class does not have a collection of JobGroups.
This was done entirely for performance reasons - when we load all the
JobContext's (approx 10) to simply display in a drop-down list on a web
page, we don't want castor to merrily go off and load all the associated
JobGroup's, and all the associated objects to the JobGroups's, etc. IMHO
this is one of castor JDO's biggest issues - how to programitaclly tell
castor which related classes to load. Lazy loading, although a step
forward, is not a solution for us as it seeems to only work inside the same
transaction. This is impractical in a MVC type application. I don't want
to keep a transaction open between a struts action class (or servlet, etc)
that retrieves a castor persisted object and a JSP where a page designer
needs to use a lazy loaded attribute.
Here is the mapping:
<!-- JobContext -->
<class name="castorjdo.JobContext"
identity="id">
<map-to table="job_context"/>
<field name="id"
type="long">
<sql name="job_context_id"
type="bigint"/>
</field>
<field name="code"
type="string">
<sql name="job_context_code"
type="char"/>
</field>
<field name="description"
type="string">
<sql name="description"
type="char"/>
</field>
</class>
<!-- JobGroup -->
<class name="castorjdo.JobGroup"
identity="id"
key-generator="MAX">
<map-to table="job_group"/>
<field name="id"
type="long">
<sql name="id"
type="bigint"/>
</field>
<field name="description"
type="string">
<sql name="description"
type="char"/>
</field>
<field name="organisation"
type="castorjdo.Organisation">
<sql name="organisation_id"/>
</field>
<field name="jobContexts"
type="castorjdo.JobContext"
required="false"
collection="collection">
<sql name="job_context_id"
many-table="job_group_context"
many-key="job_group_id"/>
</field>
</class>
The JobContext class only has getters & setters for id, code, &
description - no collection of JobGroup's. The code from the JobGroup class
pertaining to the JobContext's is:
private Collection jobContexts = new ArrayList();
public Collection getJobContexts()
{
return this.jobContexts;
}
public void setJobContexts(Collection jobContexts)
{
this.jobContexts = jobContexts;
}
brad
-----Original Message-----
From: Robert Ollila [mailto:[EMAIL PROTECTED]]
Sent: Friday, 30 November 2001 11:22 PM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] JDO class design constrained by RDBMS
relational paradigm
Brad, Bruce, and Marie,
First, thanks to all for your input. Brad (or anyone), is there any way you
could show me what the mapping file (and java classes) looks like in your
first example (many-to-many with only one of the java classes containing a
collection of the other)? Even a quick pseudo-code example would be
welcome. If you have time it would be greatly appreciated.
thanks,
Bob.
-----Original Message-----
From: Bruce Snyder [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 30, 2001 12:17 AM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] JDO class design constrained by RDBMS
relational paradigm
This one time, at band camp, Brad Clow said:
BC >u don't have to have both sides of a relationship represented in your
java
BC >objects. for example we have a many-to-many defined in the database.
BC >however only one of the two java classes involved contains a collection
of
BC >the other.
BC >
BC >we also have one-to-many relationships where we have done the opposite
to
BC >your question. the child contains a reference to the parent, but the
parent
BC >doesn't contain the collection of children.
BC >
Bob,
Brad is exactly correct. It really only depends on how you'd like
to be able to navigate the relationships in your objects.
--
perl -e 'print
unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
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
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
