Re: [jakartaee-platform-dev] [DISCUSS] Include Jakarta NoSQL in EE 11

[Scott Stark <starksm64@xxxxxxxxx>]

As stated on the issue we will be opposed to inclusion of this spec
because we have no customers asking for it. It is also not consistent
with the approach the Hibernate team has taken in abstracting
non-relational data.

On Wed, Jul 12, 2023 at 9:09 PM Edward Burns via
jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
>
> Hello Platform Dev,
>
>
>
> I have attempted to capture prior discussion about this topic from the following sources:
>
> Agendas: Previous agenda google docs
>
> 2023
>
> Monthly
> Regular
>
> 2022
> 2021
> 2020
>
> GitHub Issue: The corresponding issue in https://github.com/jakartaee/jakartaee-platform/issues.
> Platform-dev Archive: Any mails on the archive at https://accounts.eclipse.org/mailing-list/jakartaee-platform-dev.
>
> Agendas
>
> 2021
>
> [WK] Impact of using selected MP features by Jakarta implementations of NoSQL (where JNoSQL is already impacted) or say Krazo 2.x if it was to use MP REST Client or something else. The usage in specs is currently out of discussions unless the JESP was updated accordingly (jakartaee/JESP/issues/5)
>
> 2023
>
> o
>
> Jakarta NoSQL
>
> Marlow: Last week, we asked some Jakarta NoSQL questions,  https://www.eclipse.org/lists/nosql-dev/msg00232.html has answers to these and related questions.
>
> The absence of a clean JDBC style driver concept and platform spec integration is a problem. This would argue for keeping it standalone.
>
> Is this spec ready for EE 11?
>
> Invite Otavio to a Platform call in the near future
>
> Eclipse JNoSQL is currently the only implementation, seems to be good progress
>
> Jakarta Data could trigger more implementations of Jakarta NoSQL
>
>
>
> GitHub Issue https://github.com/jakartaee/jakartaee-platform/issues/660
>
>
>
> Scott Stark wrote:
>
>
>
> Red Hat will oppose this for at least two reasons. 1. we don't have users asking for this. To be part of a platform or profile there needs to be demonstrated user demand. 2. The current approach is introducing a new query language to try to abstract across implementations. This is not what users currently do, and results in a weaker feature. We looked at using the JPA API and JPQL in our https://hibernate.org/ogm/ approach in addition to exposing the native query capabilities.
>
>
>
> Werner Keil wrote:
>
>
>
> Hibernate OGM is not maintained anymore.
>
> @starksm64 Why are you opposing something new that's maintained?
> There is no new query language in Jakarta NoSQL, aside from the ability to use those of a particular NoSQL DB like
>
> CQL (Cassandra)
> Cypher (Neo4J)
> etc.
>
> Think of Native Queries in JPA.
>
> It seams reasonable for NoSQL to wait for Jakarta Data due to upstream dependencies, potentially data, although depending on what's otherwise decided between Jakarta EE and MicroProfile, MP Config may be a viable alternative, especially for the compatible implementation JNoSQL.
>
>
>
> Amos Catelli wrote:
>
>
>
> I think NoSQL is a perfect candidate.
> It will bring a rich abstracted API (KeyValue, Document, Column, Graph) over NoSQL databases.
>
>
>
> Platform-dev Archive: https://www.eclipse.org/lists/jakartaee-platform-dev/msg00782.html
>
>
>
> | edburns@xxxxxxxxxxxxx | office: +1 954 727 1095
>
> | Calendar Booking: https://aka.ms/meetedburns
>
> |
>
> | Please don't feel obliged to read or reply to this e-mail outside
>
> | of your normal working hours.
>
> |
>
> | Reply anonymously to this email: https://purl.oclc.org/NET/edburns/contact
>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev