Allow projects to choose their ID generator

[manosbatsis]

AbstractUser pretty much bars applications from using their own ID generator, as it extends LemonEntity > AbstractPersistable, with the latter defining the ID member and JPA annotations. It would be much preferable to provide an interface VS AbstractUser or otherwise not include the id member definition within it or it's superclasses. In short, users should be able to:

// OR:  implements LemonUser<Integer>
public class User extends AbstractUser<Integer> {
	@Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	private Integer id;
}

[naturalprogrammer]

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

[manosbatsis]

@naturalprogrammer can't really see how your comment relates to the issue, probably meant to post elsewhere?

[naturalprogrammer]

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?

[manosbatsis]

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.

[naturalprogrammer]

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.

[naturalprogrammer]

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>