I wouldn't label the feature with DTO but rather as some general result transformation - might also be useful for e.g. native queries. Going back to the API suggestion, from that perspective such an annotation should probably also work on method level, so I'd keep the forEntity out there.
On Wed, Jul 10, 2013 at 4:22 PM, John D. Ament <john.d.am...@gmail.com>wrote: > Personally, I don't like this idea. > > A DAO should do DAO stuff. > A DTO should do DTO stuff. > > The transformation of your entities into some other POJO shouldn't be > inside your DAO. > > Right now, I use google guava to do DTO work on entities going back and > forth over a REST API. Works well IMHO. > > John > > > On Wed, Jul 10, 2013 at 9:21 AM, Romain Manni-Bucau > <rmannibu...@gmail.com>wrote: > > > globally my answer meant "if forEntity is sometimes mandatory, sometimes > > not this is maybe not the right place" > > > > i thought to add it to mapper config > > > > *Romain Manni-Bucau* > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* > > *Blog: **http://rmannibucau.wordpress.com/*< > > http://rmannibucau.wordpress.com/> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* > > *Github: https://github.com/rmannibucau* > > > > > > > > 2013/7/10 Thomas Hug <thomas....@gmail.com> > > > > > Making forEntity non-optional would then be redundant for the regular > > cases > > > using the base interface, so I wouldn't. But I see that it should be > > > clearly documented then as things might get confusing... > > > > > > > > > On Wed, Jul 10, 2013 at 3:02 PM, Romain Manni-Bucau > > > <rmannibu...@gmail.com>wrote: > > > > > > > do you mean you force forEntity = Person.class? > > > > > > > > looks ok for me since the only constraint is to add the dto types > > > somewhere > > > > :) > > > > > > > > *Romain Manni-Bucau* > > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* > > > > *Blog: **http://rmannibucau.wordpress.com/*< > > > > http://rmannibucau.wordpress.com/> > > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* > > > > *Github: https://github.com/rmannibucau* > > > > > > > > > > > > > > > > 2013/7/10 Thomas Hug <thomas....@gmail.com> > > > > > > > > > Hmm and I assumed DTOs are dead and buried :-) > > > > > > > > > > Packing this in the base interface feels kind of clunky to me - > also > > > > > considering that there are repositories without the need to extend > > the > > > > base > > > > > interface. What about something like > > > > > > > > > > @Repository(forEntity = Person.class) > > > > > @ResultMapper(entityMapper = MapperX.class, keyMapper = > > MapperY.class) > > > > > public interface PersonRepository extends > EntityRepository<PersonDto, > > > > > DtoPk> { ... } > > > > > > > > > > Having the Entity on @Repository takes precedence and the type > > > parameters > > > > > are in this case just for convenience. > > > > > > > > > > > > > > > > > > > > On Wed, Jul 10, 2013 at 2:35 PM, Romain Manni-Bucau > > > > > <rmannibu...@gmail.com>wrote: > > > > > > > > > > > +1 > > > > > > > > > > > > just to complete this thread the main issue is not the > > implementation > > > > but > > > > > > the exposed API: > > > > > > > > > > > > public interface EntityRepository<E, PK extends Serializable> > > > > > > > > > > > > would become > > > > > > > > > > > > public interface EntityDtoRepository<E, PK extends Serializable, > > Dto, > > > > > > DtoPk> > > > > > > > > > > > > *Romain Manni-Bucau* > > > > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* > > > > > > *Blog: **http://rmannibucau.wordpress.com/*< > > > > > > http://rmannibucau.wordpress.com/> > > > > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* > > > > > > *Github: https://github.com/rmannibucau* > > > > > > > > > > > > > > > > > > > > > > > > 2013/7/10 Jean-Louis MONTEIRO <jeano...@gmail.com> > > > > > > > > > > > > > Hello guys, > > > > > > > > > > > > > > Just used DS Data module yesturday, and I was wondering if we > > could > > > > > add a > > > > > > > feature allowing on-the-fly conversion to DTO. > > > > > > > For example, we could use modelmapper (or similar to convert > DAO > > > > return > > > > > > > values to DTO objects). > > > > > > > > > > > > > > Adding a mapper interface to delegate to would also allow > people > > to > > > > > plug > > > > > > > their own implementation in. > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > JLouis > > > > > > > > > > > > > > > > > > > > > 2013/7/1 Thomas Hug <thomas....@gmail.com> > > > > > > > > > > > > > > > Hi John > > > > > > > > Thnx for the message, missed that one. Looks like there's a > > > default > > > > > > > profile > > > > > > > > needed (test-persistence.xml only part of the specific server > > > > > > profiles). > > > > > > > > Will check tonight. > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jul 1, 2013 at 2:42 AM, John D. Ament < > > > > > john.d.am...@gmail.com > > > > > > > > >wrote: > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > > > > > Whoever brought in the data module, can you double check > your > > > > tests > > > > > > and > > > > > > > > > license headers? > > > > > > > > > > > > > > > > > > I think it's just your tests, but it's failing during a rat > > > check > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://builds.apache.org/job/DeltaSpike%20RAT-Check/org.apache.deltaspike.modules$deltaspike-data-module-impl/558/testReport/org.apache.deltaspike.data.impl/QueryResultTest/org_apache_deltaspike_data_impl_QueryResultTest/ > > > > > > > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Jean-Louis > > > > > > > > > > > > > > > > > > > > > > > > > > > >
