Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "JNoSQL/Q&A"

Line 69: Line 69:
 
** You might use any CDI resource to either replace or decorate any element in Mapping layer
 
** You might use any CDI resource to either replace or decorate any element in Mapping layer
 
** The conventions still valid to Mapping layer
 
** The conventions still valid to Mapping layer
 
 
  
  
 
== Communication Layer ==
 
== Communication Layer ==
 +
  
 
=== Should a NoSQL vendor implement all types? ===
 
=== 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.
 
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 10:29, 30 June 2017

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 (Among the databases types)
    • Artemis is a JPA API to NoSQL database
    • Artemis is a parser to communication layer
    • Artemis is CDI based
    • Artemis is a parser that convert an object to/from Communication layer


What is the goal to JNoSQL?

To create a standard to NoSQL technology with Java EE as a JSR within a JCP Process. You can access the JSR Proposal here: https://goo.gl/MBdtNP


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.


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

e.g.: ... 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


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.

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 communication and its Diana implementation just going to do an adapter.

Back to the top