Re: JDO Collections
So does this mean I can only have collections of a specific element type? What about collections that hold multiple types? Is it impossible to store them? I think that specification of element types is supposed to be optional for JDO. (allowing the implementation to optimize if it is specified) In normal OJB (PB, ODMG) you specify 1:n associations (references), 1:n and m:n associations (colletions) between persistent classes (types that have a class descriptor). If you want a somewhat generic collection you have to find a common basetype of all possible element objects, which can be made persistent. Especially it needs to have primary keys. I don't know anything about JDO, but I guess it is the same there. Tom According to the book I have (which is not the spec, but hopefully the author has read and understood the spec) it has the following example: ?xml version=1.0 encoding=UTF-8? !DOCTYPE jdo SYSTEM jdo.dtd jdo package name=com.corejdo.examples.model class name=Author field name=books collection element-type=com.corejdo.examples.model.Book/ /field /class /package /jdo This looks like what you are describing, but underneath that with a bold heading is this: Additional Metadata The additional metadata shown for the books filed is optional; it does not need to be specified. If not specified the JDO runtime assumes that the colledtion may contain a reference to any persistent object, as does normal Java. Even though it is optional it is best practice to define the element type of a collection because it potentially allows the JDO runtime ot optimize how it handles the field both in-memory as well as in the datastore. From this it looks like PersistenceCapable is supposed to be the default common base type. So for my project, given the current OJB implementation is not the final implementation and it seems in this respect incomplete, I will probably just have to work around this. It probably isn't too hard as I look at my object model, but I was going to relegate this to Optimize Last. It looks like this typeless collection issue is something to think about for the final native JDO implementation. By the way does any1 know when work on the full native implementation is going to start? will it continue with the same classes and just work to replace the Sun dependancies, or will it be re-done from scratch? -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDO Collections
This is not necessarily an optimization but rather a removal of unnecessary genericity. Let me explain: in java when you use a collection, you simply say all objects in it are of type Object or subtypes thereof. This may be well but usually you only mean to put objects of type SomeBaseType or subtypes of it, into the collection. So why not using the ability of a compiler to check that you don't put objects of other types in it by accident (this is called generic types and will be available in Java 1.5 btw). Oh yes the certainly can be a good idea. I'm not against this, but with no current java mechanism for automatically enforcing this sort of thing, effort/time must be expended to enforce it manually, and thus I would only do it where it appears to be critical (such as an obvious way that wrong types could hit the collection and an exception should be thrown), or provide some form of optimization if that optimization is needed. In this case, I will do it to make OJB's jdori plug-in happy. It will be interesting to see if/how how JDO is effected by the 1.5 generics you describe. It sounds like the metadata would have to become non-optional in some cases. In JDO it is similar to Java (well actually it is the same): it is usually better though less convenient to have associations as un-generic as possible. Though here it may be more of performance reasons than static type-checking. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDO Collections
Oh yes the certainly can be a good idea. I'm not against this, but with no current java mechanism for automatically enforcing this sort of thing, effort/time must be expended to enforce it manually, and thus I would only do it where it appears to be critical (such as an obvious way that wrong types could hit the collection and an exception should be thrown), or provide some form of optimization if that optimization is needed. In this case, I will do it to make OJB's jdori plug-in happy. It will be interesting to see if/how how JDO is effected by the 1.5 generics you describe. It sounds like the metadata would have to become non-optional in some cases. Or vice versa superfluous as already present in the java type (generics). I'll also be very interested in seeing how Java 1.5 affects OJB ;-) Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDO Collections
On Fri, 6 Feb 2004, Gus Heck wrote: Tried this but I am having issues I have an person object that holds a collection of ContactInfo. People may be contacted at more than one place... etc. The contact info objects are perfectly happy not knowing who they contact (they have no reference to Person). This is an 1:n mapping, but the n contacts have no dependancy on the 1 person. The xdoclet module seems to require that the ContactInfo's all know about the Person's. This seems like a silly requirement. From the ojbdoclet documentation: foreignkey Contains one or more foreign key field or columns (separated by commas). If the collection implements an 1:n association, then this attribute specifies the fields in the element type that implement the association on the element side. Note that these fields are required to have the ojb.field From my class /** * @ojb.field * @ojb.collection auto-retrieve=true * auto-update=false * auto-delete=false */ Collection ContactsCollection; The error: Generating repository_user.xml. (XDocletMain.start 53 ) Running XDoclet failed. (XDocletMain.start 54 ) No foreign keys specified for collection ContactsCollection in type org.cs101.fdb.impl.jdo.PersonBase. build.xml [323] XDoclet failed. at xdoclet.DocletTask.start(DocletTask.java:461) at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:95) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) (the trace is about 30 miles long... I'll post it if it helps). How do I get around this? or am I forced to put in useless, backreference? The reference from the element object to the object with the collection is not at all useless. It is how OJB actually implements the 1:n association (it stores the primarykey of the object with the collection). So basically you put in a field into the element type of the same type as the primarykey. There is a way to avoid this, however, by using an indirection table (as a 1:n association is a m:n association with an implicit constraint). Here you have the foreignkeys in a separate table referencing the primarykeys of the two ends of the association. BTW, when you use a collection type (as opposed to an array), you have to specify the element type, as well (using element-class-ref). Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JDO Collections
Hi Gus, The current JDO implementation does not inherit the ODMG stuff. You should use simple java.util.Collection attributes for your collections. You'll have to define collection-descriptors with auto-retrieve=true, auto-update=false and auto-delete=false. cheers, Thomas -Original Message- From: Gus Heck [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 10:11 PM To: OJB Users List Subject: JDO Collections So I am about to embark on my first JDO class that holds a collection. (a java.util.List of some sort ideally). I notice in my book about JDO that only HashSet support is required, but I also saw in the faq that ODMG has full support for collections... Does JDO inherit this from the ODMG stuff, or do I need to choose my collections from some supported sub-set? (if this is in the docs please point me to it... I didn't find it). -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDO Collections
Mahler Thomas wrote: Hi Gus, The current JDO implementation does not inherit the ODMG stuff. You should use simple java.util.Collection attributes for your collections. Sigh. I guess that means I can't rely on the order of anything and have to sort every time I retreive if order is important and keep an listOrder or timeStamp field for lists that have arbitrary but important order? You'll have to define collection-descriptors with auto-retrieve=true, auto-update=false and auto-delete=false. This is in repository-user? in .jdo files? or both? Looks like my project for today is to figure out what xdoclet tags do what I need then... any hints? cheers, Thomas -Original Message- From: Gus Heck [mailto:[EMAIL PROTECTED] Sent: Thursday, February 05, 2004 10:11 PM To: OJB Users List Subject: JDO Collections So I am about to embark on my first JDO class that holds a collection. (a java.util.List of some sort ideally). I notice in my book about JDO that only HashSet support is required, but I also saw in the faq that ODMG has full support for collections... Does JDO inherit this from the ODMG stuff, or do I need to choose my collections from some supported sub-set? (if this is in the docs please point me to it... I didn't find it). -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDO Collections
Mahler Thomas wrote: Hi Gus, The current JDO implementation does not inherit the ODMG stuff. You should use simple java.util.Collection attributes for your collections. You'll have to define collection-descriptors with auto-retrieve=true, auto-update=false and auto-delete=false. cheers, Thomas Tried this but I am having issues I have an person object that holds a collection of ContactInfo. People may be contacted at more than one place... etc. The contact info objects are perfectly happy not knowing who they contact (they have no reference to Person). This is an 1:n mapping, but the n contacts have no dependancy on the 1 person. The xdoclet module seems to require that the ContactInfo's all know about the Person's. This seems like a silly requirement. From the ojbdoclet documentation: foreignkey Contains one or more foreign key field or columns (separated by commas). If the collection implements an 1:n association, then this attribute specifies the fields in the element type that implement the association on the element side. Note that these fields are required to have the ojb.field From my class /** * @ojb.field * @ojb.collection auto-retrieve=true * auto-update=false * auto-delete=false */ Collection ContactsCollection; The error: Generating repository_user.xml. (XDocletMain.start 53 ) Running XDoclet failed. (XDocletMain.start 54 ) No foreign keys specified for collection ContactsCollection in type org.cs101.fdb.impl.jdo.PersonBase. build.xml [323] XDoclet failed. at xdoclet.DocletTask.start(DocletTask.java:461) at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:95) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:166) at org.apache.tools.ant.Task.perform(Task.java:319) at org.apache.tools.ant.Target.execute(Target.java:309) (the trace is about 30 miles long... I'll post it if it helps). How do I get around this? or am I forced to put in useless, backreference? -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JDO Collections
So I am about to embark on my first JDO class that holds a collection. (a java.util.List of some sort ideally). I notice in my book about JDO that only HashSet support is required, but I also saw in the faq that ODMG has full support for collections... Does JDO inherit this from the ODMG stuff, or do I need to choose my collections from some supported sub-set? (if this is in the docs please point me to it... I didn't find it). -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
