Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jnosql-dev] JNoSQL Aphrodite

About the Logo, finally, we have one thank you Adolfo Eloy



On Mon, Jun 4, 2018 at 8:21 AM, Otávio Gonçalves de Santana <otaviopolianasantana@xxxxxxxxx> wrote:
That is my thoughts on Artemis integration: 


Document

   DocumentTemplate template=..;
   List<Movie> movies = template.query("select * from Movie");
 PreparedStatement preparedStatement = template.prepare("select * from Person where name = @name");
preparedStatement.bind("name", "Ada");
  DocumentTemplateAsync template=..;
 Consumer<List<Movie>> callback = l ->{};
 template.query("select * from Movie", callback);

Column

   ColumnTemplate template=..;
   List<Movie> movies = template.query("select * from Movie");
 PreparedStatement preparedStatement = template.prepare("select * from Person where name = @name");
        preparedStatement.bind("name", "Ada");
 ColumnTemplateAsync template=..;
 Consumer<List<Movie>> callback = l ->{};
 template.query("select * from Movie", callback);

Graph

GraphTemplate template = ...;
Optional<Person> person = template.singleResult("g.V().hasLabel('Person')");
GraphTemplate tempalte = ...;
PreparedStatement prepare = tempalte.prepare("g.V().hasLabel(param)");
 prepare.bind("param", "Person");
List<Person> people = prepare.getResultList();

Key-Value

KeyValueTemplate template=...;
  Optional<Person> person = template.getSingleResult("get id", Person.class);
KeyValueTemplate template=...;
PreparedStatement statement = template.prepare("get @id", Person.class);
statement.bind("id", 12);
List<Person> resultList = statement.getResultList();

Repository

    interface PersonRepository extends Repository<Person, Long> {

        @Query("g.V().hasLabel('Person').toList()")
        List<Person> findByQuery();

        @Query("g.V().hasLabel('Person').has('name', name).toList()")
        List<Person> findByQuery(@Param("name") String name);


    }

private PersonRepository repository =//needs repository to graph
 personRepository.findByQuery("Ada");
    interface PersonRepository extends Repository<Person, Long> {

        @Query("g.V().hasLabel('Person').toList()")
        List<Person> findByQuery();

        @Query("g.V().hasLabel('Person').has('name', name).toList()")
        List<Person> findByQuery(@Param("name") String name);


    }

private PersonRepository repository =//needs repository to graph
 personRepository.findByQuery("Ada");
 interface PersonRepository extends R* epository<Person, Long> {

        @Query("select * from Person")
        Optional<Person> findByQuery();

        @Query("select * from Person where id = @id")
        Optional<Person> findByQuery(@Param("id") String id);
    }

private PersonRepository repository =//needs repository either document or column
 personRepository.findByQuery("Ada");
  interface UserRepository extends Repository<User, String> {

        Optional<User> findByName(String name);

        @Query("get \"12\"")
        Optional<User> findByQuery();

        @Query("get @id")
        Optional<User> findByQuery(@Param("id") String id);
    }

private UserRepository repository =//needs repository key-value
  • Eclipse JNoSQL does not create a query Graph; it uses Gremlin from Apache Tinkerpop.
  • There isn't a single query to all kinds of NoSQL, there is a query to each NoSQL, and Query annotation won't do parser a universal question it will run from the implementation. E.g., The Query annotation might return an error if a developer writes a key-value query at the Query annotation in a Repository interface and then try to run in a Graph implementation, that will run as a gremlin, thereby a syntax error.


On Fri, Jun 1, 2018 at 6:08 AM, Otávio Gonçalves de Santana <otaviopolianasantana@gmail.com> wrote:

I started the integration within the API

On Tue, May 29, 2018 at 9:43 PM, Otávio Gonçalves de Santana <otaviopolianasantana@xxxxxxxxm> wrote:
Yes, I agree with you, if you solve this on the application layer we'll get enthusiasts, however, IMHO the price is too high.

When I started this API, as any standard process, I studied deeper NoSQL and took three steps:

  • I took a look at all solutions that already does exist in the Java world.
  • Talked with higher NoSQL user.
  • Talked with the NoSQL provider.

And the solutions that bring any behavior to the application layer usually has any performance issue. E.g.: I saw a solution that put an auto increment id on Cassandra, that sounds nice, however, to get this warranty the code created a new column family, that has this auto-increment value, and any operation it uses the highest consistency level, so that might lost availability.

That brings a nice discussion about the ORM boundaries...





On Mon, May 28, 2018 at 3:51 PM, Fernando Boaglio <fernando@xxxxxxxxxxx> wrote:
Ok Otavio,

What do you think of this idea: instead of throw an unsupported operation exception, JNoSQL implements it on its layer (as long as it is running) .

Even though it will bring more responsability to JNoSQL, for sure will bring more users too.

On Sat, May 26, 2018 at 1:53 PM, Otávio Gonçalves de Santana <otaviopolianasantana@xxxxxxxxm> wrote:


On Sat, May 26, 2018 at 11:35 AM, Fernando Boaglio <fernando@xxxxxxxxxxx> wrote:
Hi Otávio,

I liked the name, in the bow and arrow context a heart make sense. =)

This API will be able to handle DDL statements as well (create, drop, alter) ?
  That draft is just in the beginning; I didn't go through on this yet. That is something we can discuss, but almost always NoSQL databases are schemaless. It isn't in my plan to the first interaction, but we can change it. 

I am not sure I got this TTL parameter, can you elaborate a little more ?
    Thank you, that means the README.md isn't clean enough I'll improve it, also feel free to open PRs.

If I put TTL 1 day, the DML object will be available for 1 day or the data will be available in the database for one day and then removed later ?

 If I put TTL 1 day, the DML object will be available for one day or the data will be available in the database for one day and then removed later?
If the database has the TTL resource, when you do either inserts, to column or document, or put, to key-value, the entity itself will expire in the that you informed.
e.g.:

insert God (name = "Diana", age = 10, power = {"hunt", "moon"}) 1 day
insert God (name = "Apollo", age = 50, power = {"beauty", "sun"})
put {"Diana" ,  "The goddess of hunt", 1 day}
put {"Apollo" ,  "The god of Sun"}

So, just the Diana entities will expire in one day.

About how that from each database implementation, the API will request it from the database if it has otherwise will return unported operation exception. If they will remove logically or not, that will transparent to us.
I hope that is clear now. 
 Thank you for the question, if there is anything else not clear, please let me know.

Thanks.


On Sat, May 26, 2018 at 9:58 AM, Otávio Gonçalves de Santana <otaviopolianasantana@xxxxxxxxm> wrote:
Hello everyone, In the last month I was studying the good way to introduce query as String in the JNoSQL project and finally I have a draft code.

So, it was born JNoSQL Aphrodite, the project that reads and convert the query:

why this name?
I'm not creative, that is just to keep the Goodness line and the logo I thought the JNoSQL duke logo with a heart at the tip of the arrow, yeah like a cupid.

That is the syntax that I have in my mind:



Also, if you have any question, please let me know.

ps: Guys, please feedbacks as draft anything can be changed.

Thoughts?
 


--
Otávio Gonçalves de Santana

_______________________________________________
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




--

Fernando Boaglio

│◦└̅┘◦ ◦ ﴾̭▒̭̊▒̭̊﴿ ﴾̭▓̭̊▓̭̊﴿ ﴾̭░̭̊░̭̊﴿ ◦ ◦ (͡ < ◦ ● ◦└̅┘◦│

_______________________________________________
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




--
Otávio Gonçalves de Santana

_______________________________________________
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




--

Fernando Boaglio

│◦└̅┘◦ ◦ ﴾̭▒̭̊▒̭̊﴿ ﴾̭▓̭̊▓̭̊﴿ ﴾̭░̭̊░̭̊﴿ ◦ ◦ (͡ < ◦ ● ◦└̅┘◦│

_______________________________________________
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




--
Otávio Gonçalves de Santana



--
Otávio Gonçalves de Santana



--
Otávio Gonçalves de Santana



--
Otávio Gonçalves de Santana

Back to the top