I manages to partially figure out the solution to mapping multiple XML
elements to a single database table. At the bottom of the mapping.xml in the
tests directory is an example of a nested field (hey, I guessed right). So
I can do the following:
<class name="com.scenicsoft.payday.datamodel.gen.Project" identity="id">
<description>Mapping for Project</description>
<map-to table="project" xml="Project"/>
<field name="id" type="string">
<sql name="id" type="varchar"/>
</field>
...
<field name="Page.height" type="java.math.BigDecimal">
<sql name="page_height" type="numeric"/>
</field>
<field name="Page.width" type="java.math.BigDecimal">
<sql name="page_width" type="numeric"/>
</field>
...
Which is really neat, but I have a nested case that still doesn't work:
<field name="Page.display_uom"
type="com.scenicsoft.payday.datamodel.gen.types.UomType"
>
<sql name="page_display_uom" type="varchar"/>
</field>
When my app runs, Castor fails to discover the proper getter/setter methods
for this field. This is apparently because the class Page has no methods
other than the ones it inherits from its type class, DimensionType. Trying
to rectify this by using direct access or specifying the methods is no use.
Neither:
set-method="Page.setDisplay_Uom"
get-method="Page.getDisplay_Uom"
or:
set-method="Page.super.setDisplay_Uom"
get-method="Page.super.getDisplay_Uom"
find the correct method. Exception as follows:
-------
org.exolab.castor.mapping.MappingException: The method
Page.super.getDisplay_Uom in class
com.scenicsoft.payday.datamodel.gen.Project accepting/returning object of
type class com.scenicsoft.payday.datamodel.gen.types.UomType was not found
at
org.exolab.castor.mapping.loader.MappingLoader.createFieldDesc(MappingLoader
.java:746) at
org.exolab.castor.jdo.engine.JDOMappingLoader.createFieldDesc(JDOMappingLoad
er.java:246) at
org.exolab.castor.mapping.loader.MappingLoader.createFieldDescs(MappingLoade
r.java:519) at
org.exolab.castor.mapping.loader.MappingLoader.createDescriptor(MappingLoade
r.java:343) at
org.exolab.castor.jdo.engine.JDOMappingLoader.createDescriptor(JDOMappingLoa
der.java:147) at
org.exolab.castor.mapping.loader.MappingLoader.loadMapping(MappingLoader.jav
a:212) at
org.exolab.castor.jdo.engine.JDOMappingLoader.loadMapping(JDOMappingLoader.j
ava:295) at
org.exolab.castor.mapping.Mapping.getResolver(Mapping.java:278) at
org.exolab.castor.jdo.engine.DatabaseRegistry.loadDatabase(DatabaseRegistry.
java:289) at org.exolab.castor.jdo.JDO.getDatabase(JDO.java:559) at
com.scenicsoft.payday.datamodel.Payday.DBConnect(Payday.java:91) at
com.scenicsoft.payday.datamodel.Payday.doDatabaseStuff2(Payday.java:250)
at com.scenicsoft.payday.datamodel.Payday.main(Payday.java:53)
--------
BTW, I have looked at the examples in src/examples/myapp and
src/examples/jdo and they are, well, *sparse* to say the least (not also to
mention that one or two schemas are out of date, even though I fetched the
latest snapshot). The documentation for using JDO to map to database is
practically nonexistent (I have four Castor documents on my desk and it's
very hard for me to know which one to look at to get information; in
addition I've combed through other websites and have not found hardly
anything beyond barebones intro material on JDO and Castor JDO in
particular).
The test scripts have many examples, but they are abstract and it's hard to
figure out which schema goes with which test.
What would be really helpful for bootstrapping us newbies is a single
document or directory with the following:
1) a simple xsd schema with root definition and children (one-to-one and
one-to-many)
2) a set of classes generated from said schema (just to save learners an
extra step)
3) a single database create script (SQL DDL level 1)
4) a valid mapping.xml file
5) an application that populates and fetches a single class representing a
document root node.
I've not been able to find that coherent a JDO/database presentation in
either the Castor documentation or the example and source directories. The
JDO/xml-binding documentation is fine and useful, however.
For instance, I've not been able to figure out if I have to have a
back-reference to a parent from a child in order to do proper SQL mapping. I
would expect (wanly) that in a one-to-many relation, the primary-foreign key
dependency would be obvious enough given the following Project-to-Part
mapping information (one-to-many):
class name="com.scenicsoft.payday.datamodel.gen.Project" identity="id">
<description>Mapping for Project</description>
<map-to table="project" xml="Project"/>
...
<field name="Part" type="com.scenicsoft.payday.datamodel.gen.Part"
collection="arraylist"
>
<sql many-key="id_project"/>
</field>
</class>
<class name="com.scenicsoft.payday.datamodel.gen.Part"
depends="com.scenicsoft.payday.datamodel.gen.Project" identity="id">
<description>Mapping for Project.Part</description>
<map-to table="part" xml="Part"/>
<field name="id" type="integer">
<sql name="id" type="bigint"/>
</field>
</class>
Here, there should be sufficient information to know that Part is related to
Project through the foreign key "id_project". Yet, Castor seems to want to
force me to declare the following field in Part:
<field name="id_project" type="string">
<sql name="id_project" type="varchar" required="true"/>
</field>
Which, of course would require me to put a back-reference attribute to
parent id in the XML Schema definition for Part (which is silly, as it's a
contained element). I'm sure I'm completely missing the boat on this one,
but I haven't found a good example explaining this simple one-to-many
mapping issue. The closest I've come is the
Product-ProductGroup-ProductDetail mapping file, but I can't seem to find
the xml schema to go with it (the one that's there in oes/schemas is
incomplete and out of date).
Anyway, a lot of frustration after having sepend the last several days
reading everthing I can find and experimenting. I'm not quite over that
initial hump yet, as you can probably tell. ;-)
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev