extract JPQL to the new separate document

lukasj commented 3 months ago

...or establish new specification project for Jakarta EE wide Query Language(s), where the Data QL can be core, JPQL a RDBMS extension/superset and possibly another extension for NoSQL DBs

gavinking commented 3 months ago

This would be great.

starksm64 commented 2 months ago

So the steps involved would be those described in the Creation Review of the JESP:

Create a Project Proposal[^1].
Submit a Pull Request to the Jakarta EE Specifications repository using the Creation Review template.
Send an email to the Specification Committee to request a Creation Review.
Wait for a successful Creation Review before proceeding.

[^1]: It may be a good idea to socialize the idea with the Specification Committee to solicit support before proceeding with the project creation.

gavinking commented 2 months ago

@lukasj if it's fine by you, I will make a start on this process.

gavinking commented 2 months ago

@lukasj @starksm64 how does this look to you guys:

Project Proposal: Jakarta Query Language

Object-oriented query languages

A data structure in an object-oriented language is a graph of objects connected by unidirectional object references, which may be polymorphic. Some non-relational databases support similar representations. Relational databases represent relationships between entities using foreign keys, and therefore SQL has no syntactic construct representing navigation of an association. Similarly, inheritance and polymorphism can be easily represented within the relational model, but are not present as first-class constructs in the SQL language. An object-oriented query language is a dialect of SQL with support for associations and subtype polymorphism.

Historical background

Object-oriented dialects of SQL have existed since at least the early 90s. The Object Query Language (OQL) was an early example, targeting object databases, but was never widely used, since object databases were themselves not widely adopted. Hibernate Query Language (HQL) and the Enterprise JavaBeans Query Language (EJB-QL) were both introduced in 2001 as query languages intended for use with object/relational mapping. HQL was widely adopted by the Java community and was eventually standardized as the Java Persistence Query Language (JPQL) by JSR-220 in 2006. JPQL has been implemented by at least five different products and is in extremely wide use today. On the other hand, since JPQL is defined as part of the Jakarta Persistence specification, it has not been reused outside the context of object/relational mapping in Java. More recently, Jakarta Data 1.0 introduced the Jakarta Data Query Language (JDQL), a strict subset of JPQL intended for use with non-relational databases.

Proposal

The Jakarta Query Language would be defined in a separate specification, and reused by Jakarta Persistence and Jakarta Data. It would define at least: - a core language, implementable by Jakarta Data providers backed by non-relational datastore, and - an extended language, implementable by Jakarta Persistence providers or any other persistence technology backed by a relational database. Thus, the new specification would replace chapter 4 of Jakarta Persistence, and chapter 5 of Jakarta Data. This work would also involve clarifying the semantics of JPQL, which are currently somewhat underspecified. New features of JPQL, currently proposed for inclusion in JPQL 4.0, would instead be specified by the new Jakarta Query Language specification.

Scope

The new specification would define the syntax and semantics of the query language. It would not cover: - the Java APIs used to execute queries written in the language, nor - how the query language maps to, or is implemented for, any particular database technology.

gavinking commented 2 months ago

@starksm64 the Creation Review template requires a link to a specification project ... but there's no instructions on how to set up such a project.

starksm64 commented 2 months ago

There needs to be a new project created under the https://projects.eclipse.org/projects/ee4j umbrella project. I'll ask the EE4J PMC what needs to be done.

starksm64 commented 2 months ago

The parent operations guide details the steps for creating a new project: https://www.eclipse.org/projects/efsp/operations.php#efspo-creating

I'll start the socialization with the spec committee.

edbratt commented 2 months ago

There are several paths to accomplish this -- If you want to just extract it into a separate specification, you will need to create a TCK (or refactor from the existing), and write the new specification document. You could also factor this into two facets of Persistence (like JSON Supportability or CDI Code Model) -- and just work on separating the material -- while keeping it within Persistence. Then, once you are satisfied things are factored as you want them, broach the topic of splitting it into a new Specification. You could also create the new Specification and keep it in the Persistence Specification project. There is no requirement that Specifications within a single project must evolve in lock-step so, this might make it easier to manage the contents (e.g. Dependency Injection is maintained in the CDI specification project). Process wise: Separate the material, hold a Restructuring review (when you are ready to create a new specification), optionally along with a Creation review (if you want to move this into a separate specification project). Once that is all approved, move the content into the new project and move forward.

gavinking commented 2 months ago

If you want to just extract it into a separate specification, you will need to create a TCK (or refactor from the existing), and write the new specification document.

That's not really enough here. It's not just a question of splitting out JPQL, but of:

reintegrating JDQL with JPQL, and
managing their future evolution in such a way that the languages don't diverge, while meeting the needs of both Data and Persistence.

Since Jakarta Data shouldn't depend on Jakarta Persistence for its core functionality (and vice versa) it doesn't make sense for this spec to be maintained by either one of the existing projects. Instead it should be maintained by a separate project which takes account of the needs to both consumers (and, potentially, even other future consumers which don't exist today).

So I think it makes much more sense to continue down the path we've just started, which is to create a new dedicated project for this work, and invest in the promotion of an interesting new "brand": Jakarta Query.

jakartaee / persistence