Hello Oliver, sorry about the delay.
Hi all,
reading through the article I realized that some of the language you use in the APIs is at odds with the language used by the databases. E.g. with MongoDB.
DocumentEntity documentEntity = DocumentEntity.of("books");
documentEntity.add(Document.of("_id", "100"));
documentEntity.add(Document.of("name", "JNoSQL in Action"));
documentEntity.add(Document.of("pages", "620"));
DocumentEntity saved = manager.insert(documentEntity);
There's no DocumentEntity in MongoDB. What is a DocumentEntity for you is a Document in MongoDB. That's particularly at odds with your choice of "Document" to describe a field alongside its value. That's not what a document in MongoDB is. Reusing vocabulary that already has established semantics with different semantics is a huge risk, as it will significantly hinder adoption amongst people familiar with MongoDB because it's just confusing.
That's a fear point, the big issue right now at nomenclature each database has it their particular bunch of names. That's a risk, that's why we tried to define from the concepts.
The same applies to the query APIs:
select().from("books").where("_id").eq(100).build()
Nobody in the MongoDB world thinks in "select from" clauses. It's either MongoDB's sort of query-by-example or aggregations. Trying to skin a document store with a SQL cat is problematic. For comprehension reasons and for abstraction mapping reasons. If a user consistently has to keep her mind busy translating between conceptual worlds, the abstraction is of little use as it doesn't make anything simpler. It might sort of unify Couchbase and MongoDB but of what value is that if your project only runs on one of the two (I have yet to see a project running both document database or even attempting to switch)? Still it adds cognitive load as you now all of a sudden have to speak to a store through an API that uses different concepts (relational ones) or even the same vocabulary with different semantics.
Still it adds cognitive load as you now all of a sudden have to speak to a store through an API that uses different concepts (relational ones) or even the same vocabulary with different semantics.
What I also find weird is that which database a repository is tied to is defined on the injection point:
@Inject
@Database(value = DatabaseType.DOCUMENT, provider="org.jnosql.diana.mongodb.document.MongoDBDocumentConfiguration")
TodoRepository todoRepository;
Does that imply I could have a different injection point in my application that uses the TodoRepository interface to talk to a different database, e.g. a column one? What if the query methods use store specific query keywords? Why does the client code even have to bother with such setup?
I totally agree with you.
In an Application usually just have one database to each application, thereby it's not necessary. However, when there is more than one database to avoid an ambiguous exception from CDI there is this qualifier annotation from the API. But the user can create they own qualifier annotation to it.
Cheers,
Ollie
> Am 03.08.2018 um 10:40 schrieb Otávio Gonçalves de Santana <otaviopolianasantana@xxxxxxxxx>:
>
> http://www.baeldung.com/eclipse-jnosql
>
> --
> Otávio Gonçalves de Santana
>
>
> twitter: http://twitter.com/otaviojava
> site: http://about.me/otaviojava
>
> _______________________________________________
> jnosql-dev mailing list
> jnosql-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jnosql-dev
_______________________________________________
jnosql-dev mailing list
jnosql-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jnosql-dev
I'm really happy for the feedback if you have anything that we make it better, please, let me know.
