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 > > > > > > > > > >
