You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by jerome moliere <je...@gmail.com> on 2007/04/05 11:26:07 UTC
Documentation error/ API consistency / Commons Collections Bug
Hi,
just for users conveniance I want to signal one problem in the DataRow
documentation:
Map row = (Map)artistRows.get(0);
// convert row to an artist
Artist artist = (Artist)ctxt.objectFromDataRow("Artist", row); //-->
APi changes here in 2.0!!!
Using datarows I wondered about the interest of returning from returning a
Map while later usages will reclaim a DataRow instance
(like the method DataContext.createObjectFromRow() )
At last but not least I want to signal that it seems that there's a binary
incompatibility with Commons Collections 2.1.1 (as stated in the docs from
this project) so using these features require upgrade to the 3.2 commons
collections library...
Hope this helps
jerome
--
Jerome Moliere - Mentor/J
http://romjethoughts.blogspot.com/
auteur Eyrolles
Re: Documentation error/ API consistency / Commons Collections Bug
Posted by jerome moliere <je...@gmail.com>.
2007/4/5, Mike Kienenberger <mk...@gmail.com>:
>
> DataRow is a subclass of HashMap, so there's no problem with using
> Map.
yes thanks but saw it already it in javadoc
You only need to typecast the result to DataRow if you want to
> use one of the methods specific to DataRow, or if you call a method
> that requires a DataRow.
yes you 're right but in the API the DataRow type is quite allways necessary
so FOR ME, API could be more consistant and user friendly if there was no
need to explicit cast and if the method getDatRow returned a DataRow and not
like now a Map...
Jerome
On 4/5/07, jerome moliere <je...@gmail.com> wrote:
> > Hi,
> > just for users conveniance I want to signal one problem in the DataRow
> > documentation:
> >
> > Map row = (Map)artistRows.get(0);
> >
> > // convert row to an artist
> > Artist artist = (Artist)ctxt.objectFromDataRow("Artist", row); //-->
> > APi changes here in 2.0!!!
> >
> >
> > Using datarows I wondered about the interest of returning from returning
> a
> > Map while later usages will reclaim a DataRow instance
> > (like the method DataContext.createObjectFromRow() )
> >
> > At last but not least I want to signal that it seems that there's a
> binary
> > incompatibility with Commons Collections 2.1.1 (as stated in the docs
> from
> > this project) so using these features require upgrade to the 3.2 commons
> > collections library...
> >
> > Hope this helps
> > jerome
> >
> > --
> > Jerome Moliere - Mentor/J
> > http://romjethoughts.blogspot.com/
> > auteur Eyrolles
> >
>
--
Jerome Moliere - Mentor/J
http://romjethoughts.blogspot.com/
auteur Eyrolles
Re: Documentation error/ API consistency / Commons Collections Bug
Posted by Mike Kienenberger <mk...@gmail.com>.
DataRow is a subclass of HashMap, so there's no problem with using
Map. You only need to typecast the result to DataRow if you want to
use one of the methods specific to DataRow, or if you call a method
that requires a DataRow.
On 4/5/07, jerome moliere <je...@gmail.com> wrote:
> Hi,
> just for users conveniance I want to signal one problem in the DataRow
> documentation:
>
> Map row = (Map)artistRows.get(0);
>
> // convert row to an artist
> Artist artist = (Artist)ctxt.objectFromDataRow("Artist", row); //-->
> APi changes here in 2.0!!!
>
>
> Using datarows I wondered about the interest of returning from returning a
> Map while later usages will reclaim a DataRow instance
> (like the method DataContext.createObjectFromRow() )
>
> At last but not least I want to signal that it seems that there's a binary
> incompatibility with Commons Collections 2.1.1 (as stated in the docs from
> this project) so using these features require upgrade to the 3.2 commons
> collections library...
>
> Hope this helps
> jerome
>
> --
> Jerome Moliere - Mentor/J
> http://romjethoughts.blogspot.com/
> auteur Eyrolles
>