You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Harald Wellmann <hw...@gmail.com> on 2015/12/09 22:26:17 UTC
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
RE: EntityRepository + EntityManagerDelegate
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <Ma...@gtcgroup.com> 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:rmannibucau@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" <Ma...@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.de@gmail.com]
> Sent: Wednesday, December 9, 2015 4:26 PM
> To: 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
>
>
RE: EntityRepository + EntityManagerDelegate
Posted by Marvin Toll <Ma...@gtcGroup.com>.
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:rmannibucau@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" <MarvinToll@gtcgroup.com <ma...@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.de@gmail.com <ma...@gmail.com> ]
Sent: Wednesday, December 9, 2015 4:26 PM
To: dev@deltaspike.apache.org <ma...@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
RE: EntityRepository + EntityManagerDelegate
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <Ma...@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.de@gmail.com]
> Sent: Wednesday, December 9, 2015 4:26 PM
> To: 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
>
>
RE: EntityRepository + EntityManagerDelegate
Posted by Marvin Toll <Ma...@gtcGroup.com>.
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.de@gmail.com]
Sent: Wednesday, December 9, 2015 4:26 PM
To: 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
Re: EntityRepository + EntityManagerDelegate
Posted by "John D. Ament" <jo...@apache.org>.
I like the convenience of only needing to extend one interface, and like
that it still allows the old flexibility of only extending what you need.
John
On Wed, Dec 9, 2015 at 4:26 PM Harald Wellmann <hw...@gmail.com>
wrote:
> 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
>