Missing operators in DocumentCondition

[amoscatelli]

Hi @otaviojava Let's keep track of the missing operators / functionalities to extend yours DocumentCondition (https://github.com/eclipse-ee4j/nosql/issues/90) with :

1. 'Not' operator. Basic negation operator, I believe every nosql databases supports it (for sure it's supported by MongoDB and ElasticSearch).

2. InclusiveBetween + ExclusiveBetween VS Between. Same as before, also we already talked about this.

3. Allowing a 'path' on the 'Right hand side'. This is the hardest one, we need to find a way to represent a 'path' and allowing DocumentCondition operators to accept that path as a RHS. For example this allows making queries like 'retrieve every movie where critics score is higher than odience score'. You told me this is not supported at the moment so we need to work on this. If I recall correctly, both mongodb and elasticsearch support this out of the box.

What do you think ?

[otaviojava]

We have the negate negate method to Not operator.

[otaviojava]

I've created this PR to add the no method following the Java API: https://github.com/eclipse-ee4j/nosql/pull/100

[amoscatelli]

We have the negate negate method to Not operator.

oh ! that's good enough, sorry. I missed that.

Point n1 is to be considered fixed.

[amoscatelli]

@otaviojava correcly integrated on the fly ! https://github.com/eclipse/jnosql-mapping-extension/commit/67e4517355c17b29ab54caa0b07ce76d1359fb70

[amoscatelli]

@otaviojava what bout point n2 and n3 ? how can we proceed ?

[amoscatelli]

Hi @otaviojava ! Any news to make this progress ?

[otaviojava]

Sorry for the delay. For now, let's keep it. We'll work in parallel with the Jakarta Data: https://projects.eclipse.org/proposals/jakarta-data

So, what we can do is create some utilitarian classes to cover it. We can start on MongoDB to mature more the proposal.

What do you think?

[amoscatelli]

I can't really understand which are the functionalities to be modeled in jakarta-data that we may cover/use here. You have fore sure a more complete view than me so just tell me more details on what do you have in mind and let's move forward 💪.

Let's just not forget the final goal : having a complete query builder for JNoSql, with update and delete support too !

Now, what do we do ?

[otaviojava]

How about improving the MongoDB extension? right now, we have new dependencies: https://github.com/eclipse/jnosql-mapping-extension/blob/master/jnosql-mongodb-extension/pom.xml

What do you think if we move it as a dependency in build time?

[amoscatelli]

Maybe we can have a call and talk about this ? I believe I am not following you.

I added these two new dependencies :

        <dependency>
            <groupId>com.google.auto.service</groupId>
            <artifactId>auto-service</artifactId>
            <version>1.0.1</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>com.sun.codemodel</groupId>
            <artifactId>codemodel</artifactId>
            <version>2.6</version>
            <scope>compile</scope>
        </dependency>

Are talking about both of them ?

[amoscatelli]

Anyway yes @otaviojava, auto-service can be flagged as a compile time only dependency.

[otaviojava]

Yeap, if we put those as an option it would be really nice.

[amoscatelli]

@otaviojava here you are : https://github.com/eclipse/jnosql-mapping-extension/commit/1e1ba4202a847edf6f74dd69dce3b42dd054f899

BUT we can't flag com.sun.codemodel as optional, it is a required transitive dependency. What we can do, is to migrate the whole metamodel generation code to another library. This is the same decision Hibernate team also made, the metamodel generator is a separate jar.

What do you think ?

[otaviojava]

I like it.

Cassandra Mapper has a similar strategy with an annotation processor:

https://docs.datastax.com/en/developer/java-driver/4.2/manual/mapper/config/

[amoscatelli]

At the beginning, when my code was still in the main jnosql api and impl libraries, metamodel generator was indeed already a separate library.

Inside mapping extensions, how do you suggest to proceed ? Hybernate metamodel dependency is called 'hibernate-jpamodelgen', Cassandra's is called 'java-driver-mapper-processor'.

Maybe a 'jnosql-metamodel-generator-extension' ? Or 'jnosql-metamodel-processor-extension' ?

[otaviojava]

I like the jnosql-metamodel-processor-extension

[amoscatelli]

@otaviojava done : https://github.com/eclipse/jnosql-mapping-extension/compare/master...amoscatelli:jnosql-mapping-extension:master

is this good ? may I also suggest to move criteria packages to a 'jnosql-criteria-extension' ? what do you think ?

[amoscatelli]

Hi @otaviojava I made a pull request for what we agreed upon : https://github.com/eclipse/jnosql-mapping-extension/pull/64

I would like to start moving criteria packages to jnosql-criteria-extension but I need to know what you think about it

[otaviojava]

Hey @amoscatelli, we removed the communication here.

So, I'll close this one.