Hi Stephanie,
Could you please comment below about the two alternatives mentioned
in the TOPLink Builder documentation for implementing a one-to-many
relationship ?
Thanks.
At 13:20 03/09/99 -0700, Stephanie Chafe wrote:
>"Volkmann, Mark" wrote:
>
>> I've seen several messages discussing TOPLink on this list.
I've been
>> evaluating it lately and have identified a number of
restrictions it
>> imposes on the way your Java classes must be coded.
I'm interested in
>> hearing whether others have run into these same
restrictions. Am I
>> off base on any of these?
>
>>1) All object fields that are mapped to a database table
column must either
>>be public or have both get and set methods that are public.
There are many
>>cases when a class wishes to provide a get method but no set
method because
>>the field is read-only.
>
>Yes, this is a limitation in JDK 1.1.x. Under JDK 1.2.x we
can do private/protected variable access if you set up the security
permissions accordingly.
>Note that EJB imposes the limitation that all
container-managed
>fields are public fields, so TOPLink is less restrictive, even
under JDK
>1.1, since it allows method access.
>
>>2) Methods that provide access to collections must return
the collection
>>object (ex. a Vector) instead of an object such as an
Enumeration of
>>Iterator. There are many cases when a class doesn't want to
do this because
>>it doesn't want to allow callers to modify the
collection.
>
>Not exactly. Your methods can return anything you like,
including Enumerations. In JDK 1.1 our queries return Vectors, in
JDK 1.2, they may return any Collection or Map.
>TOPLink must have a mechanism to access the collection, since it
has to set the object's collection while building it. This does not have
to be the same method normally used by developers, and under JDK 1.2 it
can be private.
>
>>3) Every class on the "many end" of a one-to-many
relationship must have a
>>field that holds a reference back to the "one
end". There are many cases
>>when it is unnatural for that class to have knowledge of the
other class.
>>Even worse, if a class can be referenced by collections in
multiple other
>>classes, it must hold a reference back to each of
them.
>
>Yes this is a limitation, essentially imposed by the relational
database. Consider the case where an address object receives the
ejbStore notification. The corresponding database table contains a
foreign key to the containing object, and we need to write that
foreign key. Without a back-reference, or explicitly storing the
foreign key (which is worse) we have no way to obtain that
information.
The TOPLink Builder documentation says :
Alternatives to the one-to-one mapping back reference include
:
- use a direct-to-field mapping to map the foreign key and maintain
its value in the application. Here the object model does not require a
back reference, but the data model still requires a foreign key in the
target table.
- use a many-to-many mapping to implement a logical one-to-many.
This has the advantage of not requiring a back reference in the object
model and not requiring a foreign key in the data model. In this model
the many-to-many relation table stores the collection. It is possible to
put a constraint on the join table to enforce that the relation is a
logical one-to-many relationship.
- alternative 1 : could you explain "use a direct-to-field
mapping to map the foreign key and maintain its value in the
application" ?
- alternative 2 : could you explain "It is possible to put a
constraint on the join table to enforce that the relation is a logical
one-to-many relationship" ?
>>4) When using JDK 1.1, only Vector is supported for
one-to-many mappings,
>>not Hashtable. JDK 1.2 must be used to utilize Hashtable and
other
>>collection classes.
>
>Yes, this is a limitation under JDK 1.1. We have expanded
our support for different kinds of collections under JDK 1.2 - you can
use the standard collection classes that come with the JDK or user
defined collections that implement the Collection or Map
interfaces.
>
>
>--Stephanie
Chafe =
;
[EMAIL PROTECTED]
>The Object
People &nbs=
p;
http://www.objectpeople.com
>TOPLink Development
>613.225.8812(v) 613.225.5943(f)
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
>To unsubscribe, send email to [EMAIL PROTECTED] and include
in the body
>of the message "signoff EJB-INTEREST". For
general help, send email to
>[EMAIL PROTECTED] and include in the body of the message
"help".
>=20
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^
Patrice Thiebaud - Systems Engineer
BEA Systems - France
Tour Manhattan
6 place de l'Iris
92095 PARIS La D=E9fense C=E9dex
Tel: 33 1 41 45 70 27 Mobile: 06 08 05 95 95
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
