| Re: [nosql-dev] A newcomer's thoughts on Jakarta NoSQL |
Hi all,
I just found this interesting and important project. After reading the specification and browsing the interfaces and classes of the API it is clear to me that Jakarta NoSQL has huge potential. The task seems very challenging, so I admire the amazing work so far by the Jakarta NoSQL team and especially Otavio Santana.
I do have some concerns, however, which might be related to my misunderstanding of the specification. Anyway, I would like to share some of my initial thoughts.
My first concern is related to the separation
of the API into different NoSQL types. Large parts of the API
are defined in packages that are shared by all types and that is great. However,
regarding the interfaces that are not shared, it seems to me
that too many might be almost duplicated. For example, it
seems that the following groups of interfaces are very similar
{Column, Document, KeyValueEntity}, {ColumnEntity /
DocumentEntity}, {ColumnQuery, DocumentQuery}, and these are
only a few examples. It would be great if the API could be
smaller, bridging the differences between different NoSQL
types without duplicating interfaces, if possible. Note also
that many DBMS today are multi-model (see
https://db-engines.com/en/ranking). It may be possible to
store in the same database NoSQL data of different types.
Therefore, IMO it could be very beneficial to reduce duplicity
when possible.
In addition, the relationships between some interfaces in different parts of the API seem a bit complicated. For example, Query and its subclasses, DocumentQuery and ColumnQuery. The exact relationship is unclear to me, and may also confuse prospective users.
Another concern is dependency. The only dependency of JPA (e.g. when used outside a Java EE container) is JTA. This project, on the other hand, seems to have dependencies on quite a few other libraries, including, annotations-api, inject, json-api, and cdi-api. Although every dependency has its reasons, fewer dependencies may be more appealing.
I also think that the names of the Document and Column interfaces are a bit confusing (e.g., comparing to the term document in MongoDB), as they do not represent a document and a column but a specific pair of (name, value). Maybe DocumentValue/Element/Item and ColumnValue/Element/Item would be better, or maybe if it is possible to merge them to a single type - NameValue or NamedValue. I am also not sure why the template classes are called that way, as I would expect something like Mapper or Mapping in these names.
Regards,
Ilan Kirsh