Hi Michael, I agree that there do exist scenarios that mapping a string to a separate table could be desirable.
However, on your second suggestion. This is essentially a report query (Except that you get an Iterator to Object[] instead of an Iterator to a Map. IMO, This would be easy enough to create in your application persistence service. Wally -----Original Message----- From: Michael Mogley [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 25, 2003 12:14 PM To: OJB Users List Subject: Re: Collection of string I agree. IMO, this should not require any additional mapping definitions beyond those necessary to map the classes. It should be possible to arbitrarily request a collection of a specific field type from a mapped class, and this should be simple and easy through the API. I would even propose the ability to retrieve arbitrary subsets of a class' fields. E.g: Class MyClass { field A, field B, field C } It would be nice to do something like: Query query = QueryFactory.newQuery(MyClass.class, criteria); List fieldsToRetrieve = new LinkedList(); fieldsToRetrieve.add( fieldAMetaData ); fieldsToRetrieve.add( fieldBMetaData ); Collection retrievedFields = persistenceBroker.getCollectionByQuery(query, fieldsToRetrieve); Here, retrievedFields would be a collection of Maps. We could then do: for (Iterator itrFields = retrievedFields.iterator(); itrFields.hasNext();) { Map nextResult = (Map)itrFields.next(); Object fieldA = nextResult.get("A"); Object fieldB = nextResult.get("B"); } Or something similar. Michael ----- Original Message ----- From: "eric barbe" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, November 25, 2003 9:47 AM Subject: RE: Collection of string > Hi all, > > YES, YES, and YES, I think we need this feature ! ;o) > Why ? > First, if you want to use your database information without OJB, you > can not > do simply data reporting or analysis. > Second, if you are coding an API that can be use with a lot of heterogeneous > projects that don't use at least OJB or a database, it is not > conceptually correct to force users to use Wrapper classes. Example : > we are developping an API that allows to handle our kernel datas. > This API is use with a lot of projects and uses the standard java > types. Creating wrapper classes : > - will be diverting the developpers, > - will lost the compatibility, > - will be not consistant with the philosophy of Java, what is an > APIString ? A string, a stringbuffer ? Then you will decide to create > a second API, one for the "old users" and one > for the "OJB users" and then it will be to difficult to maintain. > > In short, YES, YES, and YES, we need this feature ! > > Best regards, > > Sorry for my english !! > > Eric > > -----Message d'origine----- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Envoye : mardi 25 novembre 2003 18:18 > A : OJB Users List > Objet : Re: Collection of string > > > Hi all, > > > Thomas Dudziak wrote: > > > > On Tue, 25 Nov 2003, eric barbe wrote: > > > > > >>Hi, > >> > >>Honestly, I did not test Hibernate, I only read the documentation. > >>Hibernate works the other way around from OBJ for modeling the XML. > >>What I saw for string list is this : <set name="names" > >>table="NAMES"> > >> <key column="GROUPID"/> > >> <element column="NAME" type="string"/> > >> </set> > >>It seem's simply. You give the "name" property, then the "table" > >>name and > >>the field (or element here) type. > >> > >>I think that Hibernate is wrapping each java object naturally. > >> > >>Regards > >> > >>Eric > >> > >>PS : see this link > >>http://www.hibernate.org/hib_docs/reference/html/collections.html#coll >>ecti > on > >>s-s1-3 > >> > > > > > > Unless I'm mistaken this seems to be something that OJB is not > > capable of, > > at least not directly. In OJB, the elements of collections have to > > have a > > class descriptor in the repository descriptor whereas Hibernate > > seems to also have the notion of "primitive" elements. > > Yes, with OJB you would have to write a simple Wrapper class that is > declared as element-class in the collection-descriptor. > > questions to the users: Do we need a feature to simplify the storage > of primitive types? > > cu, > Thomas > > > > > Tom > > > > > > > > -------------------------------------------------------------------- > > - > > 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] > --------------------------------------------------------------------- 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]
