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.
Difference between revisions of "JNoSQL/Q&A"
< JNoSQL
| Line 30: | Line 30: | ||
| − | === | + | === 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. | + | 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. |
Revision as of 08:19, 30 June 2017
Contents
Question and Answer
What is JNoSQL?
JNoSQL is a framework to help the Java EE user to use NoSQL technology so they can enjoy polyglot persistence in Java Enterprise Edition platform.
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
- Artemis is a JPA API to NoSQL database
- Artemis is a parser to communication layer
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.