A changelog is a file containing a curated, chronologically ordered list of notable changes for each project version.

Reference:

• https://keepachangelog.com/en/1.0.0/

Let's move it to the Jakarta NoSQL spec as well.

Should we have support to Record and more than a default constructor on Jakarta NoSQL?

@Entity
public record Person(@Id @NotNull Long id,  @NotBlank @Column String name){}

Ref:

• Entities <-> Records Assembler
• Jakarta EE Ambassador discussion
• Data Software Design Pitfalls on Java: Should We Have a Constructor on JPA? Dzone Article

On Jakarta NoSQL, we have two layers where the communication layer is mostly data structure, which might only change sometimes.

Should we define the default communication on Jakarta NoSQL?

Thus, we move the JNoSQL communication where we can keep the focus on both the mapping layer and the database drivers.

Inheritance is a fundamental concept of object-oriented programming and Java. NoSQL, usually, has no concept of inheritance, so persisting inheritance in a database can be tricky. Because databases have no concept of inheritance, there is no standard way of implementing inheritance in a database, so the hardest part of persisting inheritance is choosing how to represent the inheritance in the database.

The proposal to Jakarta NoSQL is to use a similar approach that JPA single table did.

Single table

Single table inheritance is the simplest and typically the best performing and best solution. In single table inheritance, a single table is used to store all of the instances of the entire inheritance hierarchy. The table will have a column for every attribute of every class in the hierarchy. A discriminator column is used to determine which class the particular row belongs to, each class in the hierarchy defines its own unique discriminator value.

Example

This example will use Notification:

Code

@Entity
@Inheritance
@DiscriminatorColumn(name="type")
public abstract class Notification {
    @Id
    private Long id;

    @Column
    private String name;

    @Column
    private LocalDate createdOn;

    public abstract void send();
}

@Entity
@DiscriminatorValue("SMS")
public class SmsNotification extends Notification {

    @Column
    private String phoneNumber;

    @Override
    public void send() {
        System.out.println("Sending message to sms: " + phoneNumber);
    }
}



@Entity
@DiscriminatorValue("EMAIL")
public class SmsNotification extends Notification {

    @Column
    private String phoneNumber;

    @Override
    public void send() {
        System.out.println("Sending message to sms: " + phoneNumber);
    }
}

@Entity
public class EmailNotification extends Notification {
    @Column
    private String email;

    @Override
    public void send() {
        System.out.println("Sending message to email: " + email);
    }
}

This annotation will work with: Document, Column and Graph, but we won't have support to key-value.

I was wondering, since there are so many references to gods and godesses mostly from ancient Greek mythology how do you find the idea of a Jakarta EE (color) themed variation of Odysseus' ship? Something like https://pexels-library.com/img/odysseus-clipart-24.html (it says share or modify) could be a basis or others like this one https://www.dreamstime.com/stock-illustration-greek-trireme-stylized-illustration-ancient-ship-image42935054 (even got an orange sail already)

Others like https://www.vectorstock.com/royalty-free-vector/greek-boat-odyssey-argonauts-for-greece-travel-vector-15882901
or slightly more abstract shapes
https://www.vectorstock.com/royalty-free-vector/greek-ancient-ship-vector-18459891
and
https://www.vectorstock.com/royalty-free-vector/greek-ancient-ship-vector-24682536
(again with an orange sail)

Maybe someone comes up with a different idea, but as Jakarta EE generally has the sail boat image, I thought it could be a nice way to use that CI and theme for NoSQL.

Following the previous feedback from the program committee:

We don't have a problem with the spec exploring this direction, but we currently have no interest in incorporating this in any profile or the platform. We'd also want to see interest and active work in a second implementation before this spec would be proposed final.

jakartaee/specifications#506 (comment)

They don't plan to move it forward as part of the Jakarta EE platform; on the other hand, we have Jakarta Data as a WIP specification that takes considerable effort to make happen.

Given this scenario, what do you think the best strategy for Jakarta NoSQL is?

I thought of some options:

• Think about moving to the Eclipse Microprofile side
• Returns the efforts to focus on JNoSQL (as a library that implements Jakarta Data) and hold Jakarta NoSQL for a while.
• Find a second implementation for Jakarta NoSQL (which company?)
• Reduce the Jakarta NoSQL scope for only mapping annotations. It makes it easier for more implementations and vendors.

Another option, I'm open to suggestions.

Check and review the JavaDoc inside the project to check if the documentation is enough and valuable to the user.

Tasks

• Communication API
• Mapping API

Similar to the name of the spec module (#14) almost every Jakarta EE repository follows a common pattern with an "api" Maven module for API code. We could/should move communication and mapping under an api layer.

NoSQL is pretty well modularized, but so far those modules rely on automatic module-names. In correlation with a Jakarta EE naming scheme for Jigsaw modules, NoSQL should define actual modules in module-info files.

Going through current spec, it feels to me more like a user-guide for particular implementation.
While having descriptive examples may be good thing to have there, I'd expect the spec document to be more "implementor centric" with defined requirements for the implementor. A user guide of particular implementation seems to be better place for (more) detailed examples as it may use also implementation-specific features.

Currently, we have two query instances for both Document and Column types.

The proposal is to increase the experience by adding two methods on both Document and Column templates.

@Inject
DocumentTemplate template;

List<Book> books = template.select(Book.class).where("category").eq("Java").execute();

template.delete(Person.class).where("id").eq("id").execute();

Both will work with the fluent query API style.

Hi @otaviojava
Let's keep track of the missing operators / functionalities to extend yours DocumentCondition (#90) with :

1. 'Not' operator. Basic negation operator, I believe every nosql databases supports it (for sure it's supported by MongoDB and ElasticSearch).

2. InclusiveBetween + ExclusiveBetween VS Between. Same as before, also we already talked about this.

3. Allowing a 'path' on the 'Right hand side'. This is the hardest one, we need to find a way to represent a 'path' and allowing DocumentCondition operators to accept that path as a RHS. For example this allows making queries like 'retrieve every movie where critics score is higher than odience score'. You told me this is not supported at the moment so we need to work on this. If I recall correctly, both mongodb and elasticsearch support this out of the box.

What do you think ?

Currently, the Jakarta NoSQL specification uses Java 11 API. However, the main goal of Jakarta EE 11 is to use the latest LTS (Long-Term Support) version of Java. Therefore, we need to update the Jakarta NoSQL API to Java 17 to keep up with the latest version of Java.

To achieve this goal, we need to update the POM.xml file to specify the Maven version that supports Java 17. Additionally, we should remove the Java 11 GitHub action and replace it with a Java 17 action.

This issue is an excellent opportunity for the first contribution to Jakarta NoSQL specification. We encourage the community to help us update the API to Java 17.

Tasks:

• Update POM.xml to specify Maven version that supports Java 17.
• Remove Java 11 GitHub action.
• Add Java 17 GitHub action.

Note: The goal of Jakarta EE 11 is to use the latest Java LTS release, which is Java 17. We should aim to use Java 17 to keep the Jakarta NoSQL specification up-to-date.

almost all data related project, such as Spring Data, MicroauntData have added ReactiveStreams/Flow support, Jakarta EE/MP also includes a ReactiveStreams operates spec.

Consider ReactiveStreams or Java Flow support.

Hi there,
first of all I want to thank you for all this wonderfull work.
Nosql was the kind of specification/abstraction Jakarta EE needed and I think that all of this (beginning with the 4 different kind of nosql interfaces) is a stroke of genius.

Let's get into business:

1. There is a typo :
   jakarta.nosql.mapping.EntityPostPersit
   should be
   jakarta.nosql.mapping.EntityPostPersist

2. I believe using interfaces to manage PrePersist & PostPersist events is a mistake.
   JPA uses annotations :
   javax.persistence.PrePersist
   javax.persistence.PostPersist

Why annotations are better ?
Imagine you have a hierarchy of MappedSuperclass, if you override EntityPrePersist methods you have to pay attention to call super implementations.
This is prone error, you may just want to "do things" in every MappedSuperclass without knowing such interfaces were already implemented.

Please consider using annotations like jpa and scanning every method (in the whole hierarchy) and call each of them to handle prepersist and post persist events :

package jakarta.nosql.mapping;

import java.lang.annotation.Target;
import java.lang.annotation.Retention;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.RetentionPolicy.RUNTIME;

/**
 * Specifies a callback method for the corresponding 
 * lifecycle event. This annotation may be applied to methods 
 * of an entity class or a mapped superclass.
 *
 * @since 1.0
 */
@Target({METHOD}) 
@Retention(RUNTIME)

public @interface PrePersist {}

and

package jakarta.nosql.mapping;

import java.lang.annotation.Target;
import java.lang.annotation.Retention;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.RetentionPolicy.RUNTIME;

/**
 * Specifies a callback method for the corresponding 
 * lifecycle event. This annotation may be applied to methods 
 * of an entity class or a mapped superclass.
 *
 * @since 1.0
 */
@Target({METHOD}) 
@Retention(RUNTIME)

public @interface PostPersist {}

I thought, this repo was already in https://github.com/jakartaee, but it seems it was not moved yet.
We should migrate it as soon as we can.

The GroupId of the Parent POM itself should contain org.eclipse.ee4j along the lines of https://github.com/eclipse-ee4j/jsonp or https://github.com/eclipse-ee4j/cdi.

Hello everyone

I'm trying to implement jakarta nosql in openliberty, but i dont have success.
Dependencies are not resolved, and package jakarta.nosql.* dont exist.
The openLiberty version is 21.0.0.2

Any help is apreciated. Regards

The pom.xml used is:

<modelVersion>4.0.0</modelVersion>
<groupId>com.module</groupId>
<artifactId>module</artifactId>
<version>1.0.0</version>
<packaging>war</packaging>

<properties>
    <maven.compiler.source>15</maven.compiler.source>
    <maven.compiler.target>15</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
</properties>

<dependencies>
	<!-- https://mvnrepository.com/artifact/jakarta.platform/jakarta.jakartaee-web-api -->
	<dependency>
	    <groupId>jakarta.platform</groupId>
	    <artifactId>jakarta.jakartaee-web-api</artifactId>
	    <version>8.0.0</version>
	    <scope>provided</scope>
	</dependency>
    <!-- https://mvnrepository.com/artifact/org.eclipse.microprofile/microprofile -->
    <dependency>
        <groupId>org.eclipse.microprofile</groupId>
        <artifactId>microprofile</artifactId>
        <version>4.0.1</version>
        <type>pom</type>
        <scope>provided</scope>
    </dependency>
    <!-- https://mvnrepository.com/artifact/org.jnosql.diana/diana-document -->
<dependency>
	    <groupId>org.jnosql.diana</groupId>
	    <artifactId>diana-document</artifactId>
	    <version>0.0.9</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.jnosql.diana/mongodb-driver -->
<dependency>
	    <groupId>org.jnosql.diana</groupId>
	    <artifactId>mongodb-driver</artifactId>
	    <version>0.0.9</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.jnosql.artemis/artemis-configuration -->
<dependency>
	    <groupId>org.jnosql.artemis</groupId>
	    <artifactId>artemis-configuration</artifactId>
	    <version>0.0.9</version>
	    <scope>provided</scope>
</dependency>
<!-- https://mvnrepository.com/artifact/org.jnosql.artemis/artemis-document -->
<dependency>
     	    <groupId>org.jnosql.artemis</groupId>
	    <artifactId>artemis-document</artifactId>
	    <version>0.0.9</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.projectlombok/lombok -->
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>1.18.18</version>
        <scope>provided</scope>
    </dependency>
	<!-- https://mvnrepository.com/artifact/com.google.code.gson/gson -->
	<dependency>
	    <groupId>com.google.code.gson</groupId>
	    <artifactId>gson</artifactId>
	    <version>2.8.6</version>
	</dependency>
</dependencies>

<build>
    <finalName>${project.artifactId}</finalName>
    <plugins>
    	<!-- https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-war-plugin -->
		<plugin>
		    <groupId>org.apache.maven.plugins</groupId>
		    <artifactId>maven-war-plugin</artifactId>
		    <version>3.3.1</version>
		</plugin>
        <!-- https://mvnrepository.com/artifact/io.openliberty.tools/liberty-maven-plugin -->
		<plugin>
		    <groupId>io.openliberty.tools</groupId>
		    <artifactId>liberty-maven-plugin</artifactId>
		    <version>3.3.4</version>
		</plugin>
    </plugins>
</build>

As discussed in today's meeting, Mar 29, we need to support the latest LST, Java 17, and be ready for the next LST version, Java 21.

This issue will create a GitHub Action, CI, to run the source code against Java 20; this won't impact the code behavior.
It is an excellent issue to the first contribution.

To-Do:

• Create a GitHub Action that runs the Jakarta NoSQL source code against Java 20
• Test the Action and ensure it correctly detects any compatibility issues
• Update the README to document the new CI support for Java 20

Either in a separate repository (as many Jakarta EE specs do) or theoretically as a module (then #15 would become mandatory to tell API and TCK apart) here we should create a TCK soon.

@otaviojava could you help me with it?

After the bigbang update, I've tried to contribute again with the jnosql-elasticsearch-driver project by setting up the TCK driver-tck-document into the POM in order to run their tests.

The tests have failed as we can see down below:

[ERROR] Tests run: 19, Failures: 3, Errors: 0, Skipped: 4, Time elapsed: 0.598 s <<< FAILURE! - in jakarta.nosql.tck.communication.driver.document.DocumentManagerTest
[ERROR] shouldSelect{DocumentArgument}[1]  Time elapsed: 0.167 s  <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <1> but was: <0>
        at jakarta.nosql.tck.communication.driver.document.DocumentManagerTest.shouldSelect(DocumentManagerTest.java:251)

[ERROR] shouldSingleResult{DocumentArgument}[1]  Time elapsed: 0.015 s  <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <true> but was: <false>
        at jakarta.nosql.tck.communication.driver.document.DocumentManagerTest.shouldSingleResult(DocumentManagerTest.java:277)

[ERROR] shouldReturnAnErrorEmptySingleResult{DocumentArgument}[1]  Time elapsed: 0.025 s  <<< FAILURE!
org.opentest4j.AssertionFailedError: Expected jakarta.nosql.NonUniqueResultException to be thrown, but nothing was thrown.
        at jakarta.nosql.tck.communication.driver.document.DocumentManagerTest.shouldReturnAnErrorEmptySingleResult(DocumentManagerTest.java:299)

[INFO] 
[INFO] Results:
[INFO] 
[ERROR] Failures: 
[ERROR]   DocumentManagerTest.shouldReturnAnErrorEmptySingleResult:299 Expected jakarta.nosql.NonUniqueResultException to be thrown, but nothing was thrown.
[ERROR]   DocumentManagerTest.shouldSelect:251 expected: <1> but was: <0>
[ERROR]   DocumentManagerTest.shouldSingleResult:277 expected: <true> but was: <false>
[INFO] 
[ERROR] Tests run: 43, Failures: 3, Errors: 0, Skipped: 4
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  48.853 s
[INFO] Finished at: 2023-01-07T21:27:13-03:00
[INFO] ------------------------------------------------------------------------

It makes me learn more about the Elasticsearch indexing process. Such process is an asynchronous process, it means, the server responses for index requests acts like an ACK signal meaning that the sent document will be indexed in another time. Such behavior causes eventual inconsistencies during the TCK test executions.

In the jnosql-elasticsearch-driver project, the tests are using the Awaitility library to handle this situation. After any document insert or update request, the execution awaits a little bit to be resumed, making sure the documents were stored or updated.

Maybe, we should use the same strategy on the TCK driver-tck-document. I could work on it!

@otaviojava what do you think about that?

At the specification we must to explain more about the annotation at the constructor and the usage with record as well.

In JPA there is ElementCollection to embed a collection of embeddable elements in the Entity, if possible add such a feature in NoSQL.

Given the world we live in, I think it would be better to avoid using entities which may be seen inappropriate by some as they may be interpreted as referring to a particular religion. Ie github itself tries to be on the safe side

Hi Team,

I think that introduction of the first Chapter ("One Mapping API, multiples databases") has some redundant information that, when removed, will improve comprehension of the content. Now the begining of the introduction is:

"Jakarta NoSQL is a Java framework that streamlines the integration of Java applications with NoSQL databases. It defines a set of APIs and provides a standard implementation for most NoSQL databases. This clearly helps to achieve very low application coupling with the underlying NoSQL technologies used in applications.

The project has two layers that define communication with NOSQL databases through API’s. There are:

Communication Layer: Contains four modules, one for each NoSQL database type: Key-Value, Column Family, Document and Graph. Compared with traditional the RDBMS world, they are like the JDBC API.

Mapping Layer: This layer is annotation-driven and uses technologies like CDI and Bean Validation, making it simple for developers to use. In the traditional RDBMS world, this layer can be compared to the Java Persistence API or object-relational mapping frameworks such as Hibernate."

The two pieces in bold:

1. It defines a set of APIs and provides a standard implementation for most NoSQL databases.
2. The project has two layers that define communication with NOSQL databases through API’s. There are: (a) Communication Layer, (b) Mapping Layer

are the same, because

• "a set of APIs" of "1)" is "Mapping Layer" of "2)" and
• "standard implementation for most NoSQL databases" of "1)" is "Communication Layer" of "2)".

So the final version of the introduction, in my opinion, should be:

"Jakarta NoSQL is a Java framework that streamlines the integration of Java applications with NoSQL databases.

The project has two layers that define communication with NoSQL databases through API’s. There are:

Mapping Layer: This layer is annotation-driven and uses technologies like CDI and Bean Validation, making it simple for developers to use. In the traditional RDBMS world, this layer can be compared to the Java Persistence API or object-relational mapping frameworks such as Hibernate.

Communication Layer: Contains four modules, one for each NoSQL database type: Key-Value, Column Family, Document and Graph. Compared with traditional the RDBMS world, they are like the JDBC API.

This clearly helps to achieve very low application coupling with the underlying NoSQL technologies used in applications."

And I think now it more clear and understandable.

Thank you,
Dmitri.

After the first beta version of Jakarta Data, let's implement it on the NoSQL specification side.

The scope of this issues includes:

• Support for both Entity and Id annotation
• Add support to Repository from Jakarta Data
• Remove and document the current Jakarta NoSQL about the migration to Jakarta Data.

Hi

I tried to use sample from the official documentation http://www.jnosql.org/docs/document.html. However I've got a pretty strange exception:

Caused by: java.lang.NoClassDefFoundError: javax/annotation/Priority
	at jakarta.nosql.ServiceLoaderSort.of(ServiceLoaderSort.java:67)

ServiceLoaderSort class from the communication-core module(version 1.0.0-b2) is defined in jakarta.nosql package but imports type from javax projects:

import javax.annotation.Priority;

Is it correct behavior?

We go to another approval at the Jakarta EE committee board, which is good news.

As the next step, I would like to create a force task to review and enhances our project documentation.

Tasks

• Readme
• Create changelog
• Review JavaDoc
• Refactoring Spec

Jakarta EE has updated to version 10.0, and Jakarta NoSQL is still on the version previous of the Jakarta big bang.

Once we have more Jakarta EE and MicroProfile vendors that support the version after the Jakarta Big bang, it is an excellent time to move forward with this upgrade.

@Query("select * from Variants where caseLevelData.biosampleId =@biosampleId skip @skip limit @limit")
List<VariantEntity> findByBiosampleId(@Param("biosampleId") String
biosampleId, @Param("skip") int skip, @Param("limit") int limit);

Unfortunately, this doesn't work either. I got an ANTLR exception:

QueryException: line 1:75 mismatched input '@skip' expecting INT

We need to add support to parameter types on skip and limit.

The Maven module specification should probably be renamed to spec along the lines of all major Jakarta EE specs like https://github.com/eclipse-ee4j/servlet-api etc.

The artifactId is already "spec".

After we decided to move Jakarta NoSQL only with the Mapping side and the regular part, we removed a considerable amount of code keeping:

The template interfaces
Mapping annotations

The goal would be to review and check the following points:

• Check if the README file is updated.
• Check if the spec has been updated.
• Check if the JavaDoc is ready.

Also, you can say that all feedbacks are welcome.

Currently, we have query support using a fluent API to both select and delete, but it has several limitations, such as evolute complex conditions.

The proposal is to add a builder method in the Query interfaces such as DocumentQuery, ColumnQuery, etc. This way, it will create more complex queries easier without using the fluent API.

Sort sortName = Sort.asc("name");
Sort sortYear = Sort.desc("year");
DocumentCondition isPoliana = DocumentCondition.eq(Document.of("name", "Poliana"));
DocumentCondition isMillennium = DocumentCondition.gte(Document.of("year", 2000));
DocumentCondition condition = DocumentCondition.and(isPoliana, isMillennium);
     
DocumentQuery query = DocumentQuery.builder("column", "column2")
                             .where(condition)
                             .sort(sortName)
                             .sort(sortYear)
                             .limit(3)
                             .skip(2)
                             .build();

Furthermore, it will make it easier to implement the Criteria API.

I am using Wildfly 21.0.0 (so I have CDI/Weld as required)

Any combination of

@Produces
@Database(DatabaseType.KEY_VALUE)
protected BucketManager produce() {
    return manager;
}

or

@Produces
protected BucketManager produce() {
    return manager;
}

Isn't enough to inject

@Inject
@Database(DatabaseType.KEY_VALUE)
private StringValueRepository repository;

or

@Inject
private StringValueRepository repository;

org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type StringValueRepository with qualifiers @database

or

org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type StringValueRepository with qualifiers @default

Of course if the Produces method returns a StringValueRepository directly, then it works.

Since this kind of "indirect" injection is mentioned in different parts of jnosql spec/documentation I wonder what I am doing wrong :

http://www.jnosql.org/spec/
http://www.jnosql.org/docs/key-value.html

Little help please ?

Thank you in advance

Hi Team,

another observation for improving content of the Introduction to "Chapter 1"...

I think that the piece:
"Vendor lock-in is one of the things any Java project needs to consider when choosing NoSQL databases. If there’s a need for a switch, other considerations include: time spent on the change, the learning curve of a new API to use with this database, the code that will be lost, the persistence layer that needs to be replaced, etc. Jakarta NoSQL avoids most of these issues through the Communication APIs. It also has template classes that apply the design pattern 'template method’ to databases operations. And the Repository interface allows Java developers to create and extend interfaces, with implementation automatically provided by a Jakarta NoSQL implementation: support method queries built by developers will automatically be implemented for them."

should become:
"_Vendor lock-in is one of the things any Java project needs to consider when choosing NoSQL databases. If there’s a need for a switch, other considerations include: time spent on the change, the learning curve of a new API to use with this database, the code that will be lost, the persistence layer that needs to be replaced, etc. Jakarta NoSQL avoids most of these issues through the APIs of Communication and Mapping Layers.

Jakarta NoSQL also has template classes that apply the design pattern 'template method’ to databases operations. And the Repository interface allows Java developers to create and extend interfaces, with implementation automatically provided by a Jakarta NoSQL implementation: support method queries built by developers will automatically be implemented for them._"

Let me know if my proposal make the content more structural and more understandable to readers.

Thank you,
Dmitri.

The README document still mentions JNoSQL everywhere, it should change to NoSQL in relevant places. Also in the CONTRIBUTING file.

A good readme helps new contributors and users. It includes the documentation itself.

The proposal here is to define sessions that make sense in all projects.

We can explore several projects and articles with this goal.

At this point, it might be worthwhile to discuss with it makes sense to return to markdown instead of asciidoc to have features such as Table Of Content.

References:

• https://github.com/spring-projects/spring-data-commons
• https://www.makeareadme.com/
• https://github.com/eclipse/microprofile-config

The structurally identical JNoSQL "spec" had the following licenses: https://github.com/eclipse/jnosql/blob/master/LICENSE
This one https://github.com/JNOSQL/nosql/blob/master/LICENSE while upgraded to EPL 2.0 does not mention the Apache License 2.0 as secondary license at all, it's lost and "replaced" by the default Java EE 8 "legacy" of GPL 2 with CPE.
How come the secondary license would suddenly change, or was it a template mistake?

As you know Jakarta NoSQL has one API to cover these NoSQL databases:

• Column
• Document
• Graph
• key-value

The domain to the first one is elementary, once we are talking about a sample name:

• jakarta.nosql.column
• jakarta.nosql.document
• jakarta.nosql.graph

The key-value is a bit difficult one even if we take a look at the convention:
https://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html

I have some suggestions:

• jakarta.nosql.value
• jakarta.nosql.kv (my favorite one and what Oracle NoSQL is using)
• any other options?

What do you think?

The hamcrest has not been updated since 2012.

Let's replace it with assertj, the same that we're running on Jakarta Data.

This repository should be transferred to https://github.com/eclipse-ee4j

Following the Jakarta Data issue about the topic:
jakartaee/data#70

The goal is to remove all get as the prefix on the methods, such as getResult, getSingleResult, and convert those to result and singleResult.

This issue will break compatibility with the previous version.

Context

TCK is an acronym for Technology Compatibility Kit, which comprises a series of tests that ensure a particular technology implementation is consistent with the corresponding specification. We aim to develop a TCK proposal design for Jakarta NoSQL, a Jakarta EE specification.

Challenges

• Create a straightforward TCK to test with the Jakarta EE environment.
• It is considering that the focus is on integrating Java/Spec and Data. That has considerable complexity, such as BASE vs. ACID, besides different types of NoSQL and particular behaviors.

Proposal:

• What I have on my mind is to create a super simple TCK that needs feel requirements such as Jupiter and AssertJ.
• Split the DI complexity out, using SPI instead of exploring inversion of Control as a supplier. Focus on Data-Driven design; once we're talking about mostly database integration with Jakarta EE.
• Once we have four APIs (core, Key-value, column, document), it is easier for the user to do the same, thus including the TCK that it needs.
• We'll explore the test guide that already does exist.

public void shouldInsert(Book book, Template template) {

assertThat(template.find(Book.class, book.id())).isEmpty();
template.insert(book);
assertThat(template.find(Book.class, book.id())).isPresent();
//more code here
}
}

Even though as Jakarta EE spec this is new, it follows what was incubating under https://github.com/eclipse/jnosql/releases in release 0.0.9, so this new spec may better stick to 0.1.0-SNAPSHOT instead of going back to 0.0.1.

At the spec, we have several concepts around NoSQL and their definition. To reduce and make the spec more cohesive, we can reduce it by removing what does not belong to API and putting links instead.

Define a Parent like all other Jakarta EE Specs:

    <parent>
        <groupId>org.eclipse.ee4j</groupId>
        <artifactId>project</artifactId>
        <version>1.0.5</version>
    </parent>

Mongo drivers itself can handle the dbref case.

{
  'title': 'test title', 
  'comments': [ uuid-1, 2, 3] //ref to comment document
}

we can add and remove comment from Post.comments node directly.