Open manosbatsis opened 5 years ago
👍 Good point. But in production apps, mostly some migration tool like Flyway would be used anyway. So, I feel like this issue isn't a high priority.
@naturalprogrammer can't really see how your comment relates to the issue, probably meant to post elsewhere?
What I meant was, when you use Flyway like libraries (recommended approach) instead of depending on hibernate to generate the DDL, the JPA annotations of the id
field are ignored anyways. Don't agree?
Not really. The real problem is the hardcoded Integer
id type. What if you want to use a UUID
or other non-integer type? Or need to implement another user interface? Long story short this is a composition VS inheritance issue. At worst this should be using generics.
Even if using evolution tools to override mappings wasn't a hack, JPA annotations are interpreted by frameworks like spring to e.g. to transparently save or update.
It's been a while though so this is not an issue anymore for us.
Thanks for elaborating. But public class User extends AbstractUser<Integer>
is your code (refer to getting started guide), which means you could replace the Integer
with anything.
But I do agree that this could be better patternized, but I had kept quick start and simplicity in mind, while meeting all requirements (like the generic ID above) when designing the API.
BTW, if it helps: it's possible to override the generation type by supplying a META-INF/orm.xml
in resources
, looking as below:
<?xml version="1.0" encoding="UTF-8"?>
<entity-mappings
xmlns="http://xmlns.jcp.org/xml/ns/persistence/orm"
version="2.2">
<mapped-superclass class="org.springframework.data.jpa.domain.AbstractPersistable">
<attributes>
<id name="id">
<generated-value strategy="IDENTITY" />
</id>
</attributes>
</mapped-superclass>
</entity-mappings>
AbstractUser
pretty much bars applications from using their own ID generator, as it extendsLemonEntity
>AbstractPersistable
, with the latter defining the ID member and JPA annotations. It would be much preferable to provide an interface VSAbstractUser
or otherwise not include theid
member definition within it or it's superclasses. In short, users should be able to: