[Bug]: Integration with JDBC

[hantsy]

Specification Version

1.0.0-RC1

Bug report

I am not sure if the v1.0 includes an integration with the raw JDBC API.

1. A simple ORM between tables and entity classes.
2. Similar to JPA, in an entity class, it can include embedded class, element collections, the entity itself owns the lifecycle.
3. In an entity, use an entity reference(proxy class wrappers, lazy, hint db access at first access) to access other entities.
4. Result mapping, automatic mapping by field naming, or use explicit mapper class .
5. Specific annotations for JDBC OR Mapping and Jdbc Operations, @Query(accept sql instead).

Additional information

@Table(name="posts)
record Post(
  @Id Long id, 
  String title, 
  Slug slug, 
  List<Bookmark> bookmarks, 
  String content, 
  LocalDateTime createdAt, 
  LocalDateTime updatedAt
){}

record Bookmark(String author, LocalDateTime createdAt){}
record Slug(String value){}
record PostSummary(String title){}

@Repository
interface PostRepsoitory {

   @Find
   List<PostSummary> findAll(PageRequest page);
}

[njr-11]

5. @Query(accept sql instead).

Jakarta Data added the Jakarta Data Query Language (JDQL) to be used as a standard query language regardless of the underlying database/driver technology. If a vendor wants to also offer SQL (or JPQL or some other vendor-specific query language), they are free to do that, but it is outside of the Jakarta Data spec which standardizes on JDQL.

Regarding the implementation of a Jakarta Data provider on JDBC vs Jakarta Persistence (or any other vendor-specific technology) for relational databases, it is intended that for the most part this will be an implementation detail of the Jakarta Data provider.

The part that gets externalized to the user is the entity model. A provider that is built on JDBC can offer the Jakarta Persistence entity model (or some subset of it) and/or might choose to provide a vendor-specific entity model, such as what you list in your example with Java record being used as an entity. In version 1.0, we did not require the use of Java records as entities for relational database access or fully define how it would work and if additional annotations would be needed as in your example. I believe the entity model of Jakarta NoSQL for non-relational does allow records to be entities and the Jakarta NoSQL entity annotations are written to allow for it, unlike those of Jakarta Persistence.

None of what is written in this issue would be properly categorized as a bug. It sounds more like a feature request. I suggest that we change its categorization frombug to enhancement and place it into the Future milestone. I would like to see where Jakarta Persistence ends up with respect to allowing records to be entities before standardizing anything in that space in Jakarta Data.

[gavinking]

Not sure I understand how something can be "raw JDBC API" and "a simple ORM" at the same time.

Either it generates SQL or it doesn't. If it does generate SQL, then I don't see how it's any different at all to a Jakarta Data implementation backed by Hibernate StatelessSession or whatever. Which is something that already exists.

1. A simple ORM between tables and entity classes.
2. Similar to JPA, in an entity class, it can include embedded class, element collections, the entity itself owns the lifecycle.
3. In an entity, use an entity reference(proxy class wrappers, lazy, hint db access at first access) to access other entities.
4. Result mapping, automatic mapping by field naming, or use explicit mapper class .
5. Specific annotations for JDBC OR Mapping and Jdbc Operations, @query(accept sql instead).

This list of features already sounds like it competes with Jakarta Persistence, even right off the starting blocks. Even before you start to creep the scope.

So look, I'm absolutely 100% implacably against the idea of growing a "mini-ORM" inside Jakarta Data. History shows that such things grow and grow until they turn into real ORMs. That's not the purpose of this spec.

Instead, we should stick to the plan of:

1. adding StatelessEntityManager to Persistence, and
2. defining integration between Data and Persistence.

We already know how to do that, and it's not an open-ended invitation to a quagmire.

[hantsy]

Regarding the implementation of a Jakarta Data provider on JDBC vs Jakarta Persistence (or any other vendor-specific technology) for relational databases, it is intended that for the most part this will be an implementation detail of the Jakarta Data provider.

Currently Hibernate and EclipseLink have their own implementation for JPA, but no project for integrating Jdbc, sometime we would like use a light-weight ORM solution like what is provided in Spring Data Jdbc.

[gavinking]

If you want a Spring JDBC-based implementation of Jakarta Data, you should be talking to the Spring folks, and asking them to implement the spec. There's absolutely zero barriers in the way of Spring doing that.

And there's nothing missing from Jakarta Data itself.

no project for integrating Jdbc

I mean, this is simply false. Both Hibernate and EclipseLink are completely based around JDBC, and both back an implementation of Jakarta Data.

Perhaps what you mean is that you would like to be able to hand-write SQL. But both Hibernate and EclipseLink already let you do that. Hibernate Data Repositories even extends Jakarta Data with the @SQL annotation for writing query methods in SQL, along with annotations like @SQLInsert and friends.

a light-weight ORM solution

This is simply not a well-defined thing. "Light weight" isn't a term that actually means anything in computing. Software doesn't have mass, so it can't weigh anything.

I guess what you really mean is that you want an ORM that's not based around stateful persistence contexts. One of those already exists today, and there's already an implementation of Jakarta Data based on it: Hibernate Data Repositories. Try it.

[hantsy]

I guess what you really mean is that you want an ORM that's not based around stateful persistence contexts.

Yes, also satisfy the project that follows data driven design firstly. Using reverse engineering, generating Entities from SQL/DB schema by Hibernate, the codes looks ugly.

One of those already exists today, and there's already an implementation of Jakarta Data based on it: Hibernate Data Repositories. Try it.

I am trying to use it in my Quarkus example projects.

[njr-11]

@hantsy After thinking some more about your example with Java records as entities, if you want that the right place to ask for it is to open an issue for an enhancement request from the Jakarta Persistence spec. Jakarta Data allows you to use the Jakarta Persistence entity model. If a future version of Jakarta Persistence were to add records to their entity model, I would expect the corresponding version of Jakarta Data to follow along with it.

[gavinking]

, if you want that the right place to ask for it is to open an issue for an enhancement request from the Jakarta Persistence spec

It's already been requested; we thought hard about it; we're not doing it.

Records just aren't an appropriate way to represent entities in Java. Among other problems:

• Java does not have immutable collection types (this already pretty much kills the idea dead)
• Even if it did, it's actually impossible to set up a graph of entities with bidirectional associations using only immutable objects (try it one day)
• Immutable objects don't work at all with stateful persistence contexts (they can work with stateless sessions)

Records are a good way to represent flat projections, as we've been discussing in #539. But you can't use them to represent the sort of interconnected object graphs that Java Persistence is designed to work with.

[Seriously, a bunch of immutable record objects connected by instances of java.util.Set is an abomination that should never be seen.]

[gavinking]

I think this issue should be closed. I think it would be a terrible idea for Jakarta Data to start growing a min-ORM that competes with JPA.

Note that in JPA 4 we're adding a stateless EntityAgent for people who don't want stateful persistence context, and that's what would typically back a Jakarta Data repository going forward.

[otaviojava]

Thus, I will close this one.