"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.

>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               http://www.objectpeople.com
TOPLink Development
613.225.8812(v) 613.225.5943(f)

===========================================================================
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".

Reply via email to