I agree it is a pretty complex object, but it allows
for nice reuse of existing objects to form a new
assignment relationship. While I look for a way to
simplify, I think I've found a bug or undocumented
feature ;)
I posted a message a couple of days ago about a
getting an
org.exolab.castor.jdo.DataObjectAccessException: Type
conversion error: could not set value of FieldMolder
of
com.apex.chronos.app.authorization.OrganizationRoleAssignment.setorganization(com.apex.chronos.app.party.Organization
organization) with value of type java.lang.Long
I thought the issue had resolved itself and was merely
a problem with my browser caching my error page.
Unfortunately, the same error popped up a couple of
builds later. After spending a couple of days trying
to hunt down my mapping error (including creating
another, pure relationship mapping of Author, Book,
and Publisher in a BookContract), I noticed that I was
getting the same type of error but with the
setPublisher method on the BookContract. Commenting
out the Publisher object on the BookContract fixed the
problem...the Author and Book objects came back just
fine when doing a query on BookContract. Comparing
the mappings, the Author, Book And Publisher field
definitions were all the same (with different column
names obviously), so I thought I was back at the same
dead end. Then I realized that the Publisher
"mapping" element in the database xml came after the
BookContract "mapping" element, while the Author and
Book (both of which worked) were positioned before the
BookContract mapping element. The same situation
existed with my original mapping of
OrganizationRoleAssignment (Person and Role were
positioned below, while Organization was positioned
above). I moved the BookContract and
OrganizationRoleAssignment mapping element in the
database xml doc to the bottom and the "Type
conversion error: could not set value of FieldMolder"
problem went away. I'm just happy I've seemingly
fixed a problem that's stalled me for 4 days and can
make sure I position mapping documents correctly in
the database file, but is this the way it should work?
BROKEN:
<database>
<mapping href="CASTOR-MAPPING-Author.xml"/>
<mapping href="CASTOR-MAPPING-Book.xml"/>
<mapping href="CASTOR-MAPPING-BookContract.xml"/>
<mapping href="CASTOR-MAPPING-Publisher.xml"/>
</database>
FIXED:
<database>
<mapping href="CASTOR-MAPPING-Author.xml"/>
<mapping href="CASTOR-MAPPING-Book.xml"/>
<mapping href="CASTOR-MAPPING-Publisher.xml"/>
<!-- Must be below reference objects to resolve
setXXX -->
<mapping href="CASTOR-MAPPING-BookContract.xml"/>
</database>
--- Bruce Snyder <[EMAIL PROTECTED]> wrote:
>
> Jon Wilmoth wrote:
>
> > I have a Role object that can be combined with a
> > Person object and a third object (i.e.
> Organization)to
> > represent an individual being assigned to an
> > particular Role. I'm planning on setting this up
> as 4
> > object mappings (3 seperate one-to-many
> relationships)
> > per role assignment. Below is what I have
> outlined
> > for an Org role assignment:
> > 1) Role - has collection of
> OrganizationRoleAssignment
> > objects
> > 2) Person - has collection of
> > OrganizationRoleAssignment objects
> > 3) Organization - has collection of
> > OrganizationRoleAssignment objects
> > 4) OrganizationRoleAssignment - has reference to a
> > Person, Role, Organization
> >
> > I've had problems trying to explicitely manage
> object
> > relationships before, and realize that there are
> > actually serveral many-to-many relationships (i.e.
> > Organization - Role) here, so I wanted to know if
> this
> > sort of mapping is supported by Castor JDO.
>
> Jon,
>
> Castor can certainly support this set of
> relationships. But whenever I
> see complex models like this I always ask myself if
> it can be simplified
> for many reaons. I'm wondering if there's really a
> reason to have this
> three way many-to-many set of relationships? Is
> there no way in which
> this can be simplified?
>
> Bruce
> --
> perl -e 'print
>
unpack("u30","<0G)[EMAIL PROTECTED]&5R\\"F9E<G)E=\\$\\!F<FEI+F-O;0\\`\\`");'
>
> The Castor Project
> http://www.castor.org/
>
> Apache Geronimo
> http://incubator.apache.org/projects/geronimo.html
>
>
>
>
-----------------------------------------------------------
>
> 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
