Hi Nick,
can you please also post the mapping of VortechsDims and StdSystem.
Ralf
Nick Stuart schrieb:
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]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
