complete (portable) support for Jakarta Persistence

[gavinking]

This proposes an implementation of #470, along with spec language properly specifying how Jakarta Data supports JPA.

[gavinking]

@njr-11 as promised, this reintroduces the support for stateless sessions.

[otaviojava]

I like this specialization!

Question: Can we have a module specific to ORM?

Instead of putting it at the core, we have a module specific to ORM/JPA.

This way, the scope of the core will still be cross-databased, and a new module/jar will be included in this specialization.

classDiagram
    Core <|-- ORM

Loading

[gavinking]

Can we have a module specific to ORM?

Ah, yeah, sure, we could.

Not sure it's really necessary since—for now at least—it's just six annotations with no dependencies on anything. But I'm not against doing that....

[gavinking]

Also, @otaviojava, you need to tell me if you want an interface OrmRepository<T,K> extends DataRepository<T, K>.

[gavinking]

Also, @otaviojava, you need to tell me if you want an interface OrmRepository<T,K> extends DataRepository<T, K>.

So here's a wrinkle: if you want such an interface, we would probably need to pick up a dependency to Jakarta Persistence, which would argue in favor of a separate module.

Here's I guess what it would look like, approximately:

/**
 * <p>A built-in repository supertype for repositories backed by a Jakarta Persistence
 * {@code EntityManager}.</p>
 *
 * @param <T> the type of the primary entity class of the repository.
 * @param <K> the type of the Id attribute of the primary entity.
 */
public interface OrmRepository<T, K> extends DataRepository<T, K> {

	@Find
	T find(K id);

	@Find
	T find(K id, FindOption... options);

	@Persist
	void persist(T entity);

	@Persist
	void persistAll(Iterable<T> entities);

	@Remove
	void remove(T entity);

	@Merge
	T merge(T entity);

	@Detach
	void detach(T entity);

	@Refresh
	void refresh(T entity);

	@Refresh
	void refresh(T entity, RefreshOption... options);

	@Lock
	void lock(T entity, LockModeType lockModeType);

	@Lock
	void lock(T entity, LockModeType lockModeType, LockOption... options);

	EntityManager entityManager();

}

[gavinking]

Note that I don't personally find that interface very compelling. It's just sort of a worse EntityManager.

[graemerocher]

should be called jakarta.data.jpa, since ORM is too generic and broad a term and some of these annotations whilst they look useful are JPA/Hibernate specific

[gavinking]

I'm not happy with "orm" either, but as I have the impression that the Jakarta spec aren't using the name "JPA" anymore. The JPA spec itself doesn't use the term, it's "Jakarta Persistence" everywhere.

(I think this is stupid, FTR, and I'm fine with "jpa".)

[otaviojava]

Once the Jakarta Persistence uses the jakarta.persistence, how about:
jakarta.data.persistence

At the end, it is a specialization of Jakarta Data to Jakarta Persistence.

[gavinking]

how about: jakarta.data.persistence

Fine by me.

[hantsy]

JPA is more common for developers, we are familiar with jpa, cdi, etc in Jakarta EE world.

[otaviojava]

Member Author

Also, @otaviojava, you need to tell me if you want an interface OrmRepository<T,K> extends DataRepository<T, K>.

Yeap, once ORM is a specialization of DataRepository.

[otaviojava]

Also, @otaviojava, you need to tell me if you want an interface OrmRepository<T,K> extends DataRepository<T, K>.

So here's a wrinkle: if you want such an interface, we would probably need to pick up a dependency to Jakarta Persistence, which would argue in favor of a separate module.

Here's I guess what it would look like, approximately:

/**
 * <p>A built-in repository supertype for repositories backed by a Jakarta Persistence
 * {@code EntityManager}.</p>
 *
 * @param <T> the type of the primary entity class of the repository.
 * @param <K> the type of the Id attribute of the primary entity.
 */
public interface OrmRepository<T, K> extends DataRepository<T, K> {

	@Find
	T find(K id);

	@Find
	T find(K id, FindOption... options);

	@Persist
	void persist(T entity);

	@Persist
	void persistAll(Iterable<T> entities);

	@Remove
	void remove(T entity);

	@Merge
	T merge(T entity);

	@Detach
	void detach(T entity);

	@Refresh
	void refresh(T entity);

	@Refresh
	void refresh(T entity, RefreshOption... options);

	@Lock
	void lock(T entity, LockModeType lockModeType);

	@Lock
	void lock(T entity, LockModeType lockModeType, LockOption... options);

	EntityManager entityManager();

}

Yes, this was the main reason for proposing the module. Thus, you can go deep into Jakarta's Persistence to create a better user experience without impacting the code.

[gavinking]

Yes, this was the main reason for proposing the module. Thus, you can go deep into Jakarta's Persistence to create a better user experience without impacting the code.

Yeah, sure, makes sense. I have no objection to that. Just don't expect me to do Maven things 'cos I'm clueless :-)

[otaviojava]

Yes, this was the main reason for proposing the module. Thus, you can go deep into Jakarta's Persistence to create a better user experience without impacting the code.

Yeah, sure, makes sense. I have no objection to that. Just don't expect me to do Maven things 'cos I'm clueless :-)

I can use your branch as a base to propose this new module.

[gavinking]

I can use your branch as a base to propose this new module.

Perfect.

[gavinking]

Closing this since #480 was merged instead.