Alright did some digging around and have run across a problem.
Look a few messages up in this thread and take a look at my mapping
for VortechsDims, in there I have the following field:

        <field name="castManuals"
type="com.vort.ads.vortechs.beans.VortechsManuals" required="true">
          <sql many-key="systemId"/>
        </field> 

Which is mapped as:

     <class name="com.vort.ads.vortechs.beans.VortechsManuals" 
        identity="id"
depends="com.vort.ads.vortechs.beans.VortechsDims"
key-generator="IDENTITY">
        <cache-type type="unlimited" />
        <map-to table="prjdimsmanual" />
        <field name="id" type="integer">
          <sql name="id" type="integer" />
        </field>
        <field name="system" type="com.vort.ads.vortechs.beans.VortechsDims">
          <sql name="systemId" /> 
        </field>
        .....
    </class>

And when I go to load this class I get the following exception:
org.exolab.castor.jdo.PersistenceException: Requested to load/fetch an
object of type com.vort.ads.vortechs.beans.VortechsDims, where
persistent storage returned an object of type class
com.vort.ads.beans.StdSystem
        at 
org.castor.persist.TransactionContext.load(TransactionContext.java:661)
        at 
org.castor.persist.TransactionContext.load(TransactionContext.java:550)
        at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:895)
        at org.exolab.castor.persist.LockEngine.load(LockEngine.java:368)
        at 
org.castor.persist.TransactionContext.load(TransactionContext.java:713)
        at 
org.castor.persist.TransactionContext.load(TransactionContext.java:550)
        at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:895)
        at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:819)
        at org.exolab.castor.persist.LockEngine.load(LockEngine.java:368)
        at 
org.castor.persist.TransactionContext.load(TransactionContext.java:713)
        at 
org.castor.persist.TransactionContext.load(TransactionContext.java:550)
        at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:939)
        at org.exolab.castor.persist.LockEngine.load(LockEngine.java:368)
        at 
org.castor.persist.TransactionContext.load(TransactionContext.java:713)
        at 
org.castor.persist.TransactionContext.load(TransactionContext.java:550)
        at org.exolab.castor.jdo.engine.DatabaseImpl.load(DatabaseImpl.java:345)
        at org.exolab.castor.jdo.engine.DatabaseImpl.load(DatabaseImpl.java:312)

Hmmm...well that kind of makes sense, VortechsDims is extended from
StdSystem, but it seems like Castor is trying to return just the
StdSystem and not the extended VortechsDims of the class.

If I change it around so that manuals expects the StdSystem class it
loads, but then throws other errors about linked object not being
updated and such.

I'll poke around some more to see if I can find out why the StdSystem
class and not VortechsDims is being returned.

-Nick

On 8/9/05, Nick Stuart <[EMAIL PROTECTED]> wrote:
> Well thats what I thought, but why then can I create all the objects
> fine? Wouldn't I get a "No such column" error or some such on the
> insert statment?
> 
> I'll add some logging statments in there tomorrow and see where it
> really goes bad.
> 
> Have a good flight!
> -nick
> 
> On 8/9/05, Werner Guttmann <[EMAIL PROTECTED]> wrote:
> > Nick,
> > it's getting too late here, and I got to catch a plane tomorrow morning.
> > But it looks to me from looking at the stacktrace that theres a <sql>
> > element out there that dot *not* have any columns mapped to itself.
> > Hence the NPE.
> >
> > Werner
> >
> > Nick Stuart wrote:
> > > No on the XML artifacts (dont use that side of castor for this
> > > program). Also, my hierarchy looks something like this.
> > > System1
> > > System2 extends System1
> > > System3 extends System1
> > >
> > > Thats all there is to it. System3 has some dependent objects attached
> > > directly to it, but other then that they are pretty straight forward.
> > > Here are the mapping headers for each class:
> > >     <class name="com.vort.ads.beans.Project" identity="id">
> > >         <map-to table="prjinfo" />
> > >         <field name="id" type="integer">
> > >             <sql name="id" type="integer" />
> > >         </field>
> > >         .....
> > >         <!-- These are the child poly classes -->
> > >         <field name="stdSystems" type="com.vort.ads.beans.StdSystem"
> > > collection="collection">
> > >             <sql many-key="projectNumber"/>
> > >         </field>
> > >     </class
> > >     <class name="com.vort.ads.beans.StdSystem"
> > >             identity="id"
> > >             key-generator="IDENTITY">
> > >         <map-to table="prjstddims"/>
> > >         <field name="id" type="integer">
> > >             <sql name="id" type="integer"/>
> > >         </field>
> > >         <!-- When I go to load the project, it gives me the errors -->
> > >         <field name="project" type="com.vort.ads.beans.Project" 
> > > required="true">
> > >             <sql name="projectNumber" />
> > >         </field>
> > >         .....
> > >     </class>
> > >     <class name="com.sw360.adp.stormfilter.beans.StormFilter"
> > >             identity="id"
> > >             extends="com.vort.ads.beans.StdSystem">
> > >         <cache-type type="count-limited" capacity="30"/>
> > >         <map-to table="prjsfdims" />
> > >         <field name="id" type="integer">
> > >             <sql name="id"/>
> > >         </field>
> > >         ....
> > >     </class>
> > >
> > >     <class name="com.vort.ads.vortechs.beans.VortechsDims"
> > >             identity="id"
> > >             extends="com.vort.ads.beans.StdSystem">
> > >         <cache-type type="count-limited" capacity="30"/>
> > >         <map-to table="prjdims" />
> > >         <field name="id" type="integer">
> > >             <sql name="id" type="integer" />
> > >         </field>
> > >         ....
> > >     </class>
> > >
> > > Its strange, because like I said, before I got rid of the extra/old
> > > fields in the prjdims table. After that it started throwing the NPE
> > > exception when I was trying to load the project.
> > >
> > > Thanks! -Nick
> > >
> > > On 8/9/05, Werner Guttmann <[EMAIL PROTECTED]> wrote:
> > >
> > >>Nick,
> > >>
> > >>could it be that you've got fields that are mapped to an XML artefact
> > >>but not to Castor JDO ?
> > >>
> > >>Werner
> > >>
> > >>Nick Stuart wrote:
> > >>
> > >>>Ok, going through doing refactoring to test out the polymorphism
> > >>>support and such and came accross another bug (i think).
> > >>>
> > >>>Anyways, good news first! Poly worked great when I only had one 
> > >>>subclass!  =)
> > >>>
> > >>>Now bad news, when I added another subclass things seem to have borked
> > >>>on object load time. If my datasets are all empty I can create the
> > >>>classes/objects fine, no errors or nothing. BUT when I go to load the
> > >>>classes from the database I get a NPE with the following trace:
> > >>>
> > >>>java.lang.NullPointerException
> > >>>      at 
> > >>> org.exolab.castor.jdo.engine.SQLEngine.calculateNumberOfFields(SQLEngine.java:1400)
> > >>>      at org.exolab.castor.jdo.engine.SQLEngine.load(SQLEngine.java:1194)
> > >>>      at 
> > >>> org.exolab.castor.persist.ClassMolder.loadFields(ClassMolder.java:741)
> > >>>      at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:792)
> > >>>      at org.exolab.castor.persist.LockEngine.load(LockEngine.java:368)
> > >>>      at 
> > >>> org.castor.persist.TransactionContext.load(TransactionContext.java:713)
> > >>>      at 
> > >>> org.castor.persist.TransactionContext.load(TransactionContext.java:550)
> > >>>      at org.exolab.castor.persist.ClassMolder.load(ClassMolder.java:932)
> > >>>      at org.exolab.castor.persist.LockEngine.load(LockEngine.java:368)
> > >>>      at 
> > >>> org.castor.persist.TransactionContext.load(TransactionContext.java:713)
> > >>>      at 
> > >>> org.castor.persist.TransactionContext.load(TransactionContext.java:550)
> > >>>      at 
> > >>> org.exolab.castor.jdo.engine.DatabaseImpl.load(DatabaseImpl.java:345)
> > >>>      at 
> > >>> org.exolab.castor.jdo.engine.DatabaseImpl.load(DatabaseImpl.java:312)
> > >>>
> > >>>I ran the query that caster spits out from logging and the fields of
> > >>>the opposite class I am loading are all NULL (which makes sense), but
> > >>>I dont know if this has anything to do with it or not.
> > >>>
> > >>>I'm not sure what I can do to provide any more info on this. This was
> > >>>all working at one point, but then I got rid of the extra fields in
> > >>>one of my database tables during refactoring and things busted. :(
> > >>>But none of those fields should have even been affecting anything, and
> > >>>like I said, I can create objects just fine!
> > >>>
> > >>>Any ideas on whats going on?
> > >>>Thanks!
> > >>>-Nick
> > >>>
> > >>>-------------------------------------------------
> > >>>If you wish to unsubscribe from this list, please
> > >>>send an empty message to the following address:
> > >>>
> > >>>[EMAIL PROTECTED]
> > >>>-------------------------------------------------
> > >>>
> > >>>
> > >>
> > >>
> > >>-------------------------------------------------
> > >>If you wish to unsubscribe from this list, please
> > >>send an empty message to the following address:
> > >>
> > >>[EMAIL PROTECTED]
> > >>-------------------------------------------------
> > >>
> > >>
> > >
> > >
> > > -------------------------------------------------
> > > If you wish to unsubscribe from this list, please
> > > send an empty message to the following address:
> > >
> > > [EMAIL PROTECTED]
> > > -------------------------------------------------
> > >
> > >
> >
> >
> > -------------------------------------------------
> > If you wish to unsubscribe from this list, please
> > send an empty message to the following address:
> >
> > [EMAIL PROTECTED]
> > -------------------------------------------------
> >
> >
>

-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:

[EMAIL PROTECTED]
-------------------------------------------------

Reply via email to