Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
- 1 Question and Answer
- 1.1 What is JNoSQL?
- 1.1.1 How JNoSQL solve this issue?
- 1.1.2 What is the goal to JNoSQL?
- 1.1.3 Why does not make the NoSQL connection with JPA?
- 1.1.4 Standard and NoSQL does it make sense?
- 1.1.5 Does JNoSQL is against Spring Data?
- 1.1.6 How does JNoSQL solve the diversity issue?
- 1.1.7 Why should a NoSQL provider join in this Project?
- 1.1.8 What is the Current JNoSQL status?
- 1.1.9 Who can I start in JNoSQL?
- 1.2 Communication Layer
- 1.3 Mapping Layer
- 1.1 What is JNoSQL?
Question and Answer
What is JNoSQL?
How JNoSQL solve this issue?
JNoSQL has two layers a communication, to connect NoSQL to Java, and mapping layer, an easier integration that abstract the Java model and communication layer:
- Communication API: An API just to communicate with the database, exactly what JDBC does to SQL. This API is going to have four specializations, one for each kind of database.
- The Communication layer has the aka Diana
- Diana has an API to each NoSQL type.
- Each API brand has a TCK.
- A Technology Compatibility Kit (TCK) is a suite of tests that at least nominally checks a particular alleged implementation of a NoSQL vendor for compliance.
- Mapping API: An API to do integration and do the best integration with the Java developer. That is going to be annotation drive and going to have integration with other technologies like Bean Validation, etc.
- The Mapping layer has the aka Artemis
- Artemis has Commons annotations (Among the databases types)
- Artemis is a JPA API to NoSQL database
- Artemis is a parser to a communication layer
- Artemis is CDI based
- Artemis is a parser that converts an object to/from Communication layer
What is the goal to JNoSQL?
Why does not make the NoSQL connection with JPA?
JPA has the duty to do a mapping API to make a connection between Java Model and SQL database. The relational database has a particular behavior that does not belong to NoSQL technology such as transaction, SQL based, ACID; there is just one branch instead of four as NoSQL databases. So different technology results in a different standard. Nonetheless, the JNoSQL tries to keep the JPA nomenclature.
Standard and NoSQL does it make sense?
The specific features of NoSQL matter to NoSQL technology and has relevance to JNoSQL project. It is flexible and extensible enough to use specific integration on NoSQL technology. However, in NoSQL has general behaviors such as retrieve, delete, update and insert operation that conduct will go to API and what left to a particular implementation.
Does JNoSQL is against Spring Data?
No, Spring Data is a huge inspiration to this Project, further, it is helping us with feedback and experience. Spring might have support to Communication layer even does not want to support the mapping layer.
How does JNoSQL solve the diversity issue?
Just remember, JNoSQL has two layers, communication, and mapping:
- On the Communication layer, the idea is using specializations but also using conventions such as nomenclature, return type, etc. e.g.:
- Period to TTL instead of (long to seconds, int to seconds, long to milliseconds, int milliseconds).
- Use the search as method name when the NoSQL has a search engine.
- Try to interact using the API types:
List<DocumentEntity> cql(String cql);//Cassandra Query Language
- Use the method names to insert, update, delete, select to CRUD operation even you to have additional parameters
... insert(DocumentEntity entity, Consistency Level);
- To know more about conventions click here
- On Mapping layer, we're using CDI extensions, so:
- You might have specific annotations to a particular database
- You might use any CDI resource to either replace or decorate any element in Mapping layer
- The conventions still valid to Mapping layer
Why should a NoSQL provider join in this Project?
- Helps Java Community to grow up in NoSQL Technology
- Makes NoSQL technology more popular to Java Developer, mostly the Java EE ones.
- Once the JSR begins, the Provider will show at the JSR page either a contributor or expert group team of this JSR.
What is the Current JNoSQL status?
- JNoSQL has been approved to Eclipse Foundation
- JNoSQL has dual license
- The code is on GitHub as Eclipse Foundation
- JNoSQL has a Github Organization
- We're preparing the JSR
- Try to involve as many NoSQL as we can.
Who can I start in JNoSQL?
- Join us on the email list
- Check the Diana Demo and Artemis demo
- Give us feedback
- Have fun with polyglot persistence
Should a NoSQL vendor implement all types?
No, the project works as a module, in other words, you can apply just one API, e.g. Document, without a care about other ones, e.g. Key-Value API. However, if a vendor is a multi-model, the database should implement its specifics type, eg: Couchbase implements both key-value and document.
Does make sense to the NoSQL provider keep two drivers?
No, the communication layer, Diana, allows being a slight adapter layer. So the NoSQL does not need to keep two drivers just one. So a provider has a driver and its Diana implementation just going to do an adapter.
Once the NoSQL provider is helping in this project, are they also helping the competitors?
No, they're helping mostly the Java community, besides the standard API is a slight layer and will not cover specific behavior, configuration, performance issue, etc.
Why not JPA?
JPA is created to relational database technology, so it doesn't have the focus to work with NoSQL technology, and also it's not extensible to cooperate with the diversity that there is on NoSQL technology.
Do we have specific annotations map?
To map an Entity the Artemis has annotations that were inspired in both JPA and Spring Data, so @Entity and @Column to assign an entity and its fields will cover all NoSQL types. But, the Artemis is extensible enough to a particular vendor has its annotations, e.g., Cassandra might use an annotation to identify user defined type.