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:rmannibu...@gmail.com] 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" <marvint...@gtcgroup.com <mailto:marvint...@gtcgroup.com> > 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:hwellmann...@gmail.com <mailto:hwellmann...@gmail.com> ] Sent: Wednesday, December 9, 2015 4:26 PM To: dev@deltaspike.apache.org <mailto:dev@deltaspike.apache.org> 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
