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#collecti
> 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]
