Bruce,
now, what you described below is quite unlikely to happen for a variety of reasons. But
first, let me show you the relevant fragments of the mapping file before going into
detail:
<class name="com.msdw.futopt.expiry.accounts.AccountNature" identity="identifier">
<cache-type type="count-limited" capacity="10"/>
<description>Represents an account nature.</description>
<map-to table="TLDR.OK_ACCT_NATR" />
<field name="identifier" type="short">
<sql name="ACCT_NATR_ID" type="smallint"/>
</field>
<field name="description" type="string">
<sql name="ACCT_NATR_NM" type="char"/>
</field>
</class>
<!-- Account Classification -->
<class name="com.msdw.futopt.expiry.accounts.AccountClassification"
identity="identifier">
<cache-type type="count-limited" capacity="5"/>
<description>Represents a product category.</description>
<map-to table="TLDR.OK_ACCT_CLASS" />
<field name="identifier" type="short">
<sql name="ACCT_CLASS_ID" type="smallint"/>
</field>
<field name="description" type="string">
<sql name="ACCT_CLASS_NM" type="char"/>
</field>
</class>
<!-- account -->
<class name="com.msdw.futopt.expiry.accounts.Account" identity="identifier">
<cache-type type="time-limited" capacity="15" />
<description>Represents an Account.</description>
<map-to table="TLDR.OK_VW_LDR_ACCT" />
<field name="identifier" type="string">
<sql name="ACCT_ID" type="char"/>
</field>
<field name="description" type="string">
<sql name="ACCT_NM" type="char"/>
</field>
<field name="companyCode" type="string">
<sql name="CO_CD" type="char"/>
</field>
<field name="nature" type="com.msdw.futopt.expiry.accounts.AccountNature"
lazy="true">
<sql name="ACCT_NATR_ID" />
</field>
<field name="classification"
type="com.msdw.futopt.expiry.accounts.AccountClassification" lazy="true">
<sql name="ACCT_CLASS_ID" />
</field>
</class>
As you can see, both AccountNature and AccountClassification are set to be cached with
an
upper limit of 5/15 instances in the cache. Both tables actually contain read-only data
(though not mapped accordingly in the mapping descriptor as I am playing with these
things
and I still prefer to address one thing at a time) and hence the capacity values are
enough.
As shown above, Account has 1:1 relationships to each of the other types, and that's
where
I do not understand as to how this would relate to the use of collections as pointed
out by
you.
Now, showing you the code is not really easy as we have developed our own persistence
framework that allows us to use Castor in J2EE containers and stand-alone, aand even
resort
to plain SQL code whenever required.
But, to explain things in a bit more detail ...
a) all these "reference objects" work perfectly as we have a dozen or so use cases that
make use of AccountNatures and AccountClassifications in our system, and everything
works
fine as long as I do not try to turn on lazy loading.
b) I'll do some homework, iow turn off lazy loading once again and check whether some
of
these Account instances do not have natures and/or classifications set.
And most importantly, thanks for your help so far ...
Werner
Bruce Snyder wrote:
> This one time, at band camp, Werner Guttmann said:
>
> WG>I am a bit confused right now. Just using plain SQL, I can successfully verify
>that
> WG>the foreign keys in the underlying table for the Account object are populated.
> WG>
> WG>I just had a look at the source code of ClassMolder.java, and that's what I found:
> WG>
> WG>// lazy loading for object (hollow object) is not support in
> WG>// this version. Warns user if lazy loading is specified.
> WG>if ( _fhs[i].isLazy() )
> WG> System.err.println( "Warning: Lazy loading of object is not yet support!" );
> WG>
> WG>Could somebody please be so kind and explain to me what a *hollow* object is in
>this
> WG>context ? As it looks that hgis might be the problem.
>
> This is exactly where the exception is thrown. Like I said, I *think* a hollow
> object is one that contains nothing possibly like so:
>
> Foo foo;
> Bar bar;
>
> db.begin();
>
> foo = new Foo();
> foo.setId( 1 );
> foo.setName( "Foo" );
>
> bar = new Bar();
> foo.setBar( bar );
>
> db.create( foo );
> db.commit();
>
> This is only from memory, so I can't be sure this description is correct.
>
> I'd like to see your client code and your mapping descriptor to see what
> you're doing that is causing this exception to be thrown.
>
> Also, the FAQ item I sent you yesterday is, in fact, incorrect. Just
> yesterday I checked in an updated version of the JDO examples that
> contains a working many-to-many relationship. The test is not complete,
> it still needs to be cleaned up and the marshalling bug is not yet
> fixed. At any rate, take a look at the example and compare it to what
> you're trying to do.
>
> Bruce
> --
> 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
