[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jnosql-dev] A Guide to Eclipse JNoSQL
|
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.
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.
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?
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
Attachment:
signature.asc
Description: Message signed with OpenPGP