Sure, what I dont like is starting to give multiple synonyms and then making user learning curve harder and not really explainable. Also if I come and say I want "create" should we add it?
AFAIK extending data is just a matter of writing your own interface and extending the default impl so easy enough to be done when you want IMO keeping data API itself simple and less low levelthan JPA - otherwise added value is not obvious and usages will be not as justified as it should I think. Le 10 déc. 2015 03:15, "Marvin Toll" <[email protected]> a écrit : > Romain - I’m not clear on the term “data design”? In what ways does > exposing the specification backed JPA API break “data design”? > > > > Or, perhaps you are referencing Eric Evens “Repository Pattern” and > asserting that by mixing the JPA API and the DeltaSpike Repository API in > the same class causes “breakage”? > > > > Would you mind elaborating? > > > > _Marvin > > > > *From:* Romain Manni-Bucau [mailto:[email protected]] > *Sent:* Wednesday, December 9, 2015 6:03 PM > *Subject:* RE: EntityRepository + EntityManagerDelegate > > > > Doesnt it break data design? Why not using the em if it is what you need? > One doesnt prevent the other. > > Le 9 déc. 2015 23:12, "Marvin Toll" <[email protected]> a écrit : > > Without having the benefit of "test driving" the change, it seems to make > a lot of sense to me. Any approach enabling direct access to the (native) > JPA API can only be beneficial when it is impossible to imagine all of the > different use cases that might emerge for hundreds of developers over the > next decade. > > _Marvin > > -----Original Message----- > From: Harald Wellmann [mailto:[email protected]] > Sent: Wednesday, December 9, 2015 4:26 PM > To: [email protected] > Subject: EntityRepository + EntityManagerDelegate > > For the benefit of all DS Data users who prefer persist() and merge() over > save(), I propose to extend the Data API by something like this: > > > public interface FullEntityRepository<E, PK extends Serializable> > extends EntityRepository<E, PK>, EntityManagerDelegate<E> { > } > > > public abstract class AbstractFullEntityRepository<E, PK extends > Serializable> > extends AbstractEntityRepository<E, PK> > implements EntityManagerDelegate<E> { > > } > > I don't really care about the exact class names (Full, Extended, you > name it), the point is that end users can simply write > > public interface CustomerRepository extends > FullEntityRepository<Customer, Long> {} > > to get access to all EntityManager methods. > > What do you think? > > Regards, > Harald > >
