Spring Data support for NOT Containing expression [DATACMNS-581]

[spring-projects-issues]

Sergio Correa opened DATACMNS-581 and commented

It's related to dynamic repository method naming.
Spring does allow to define method such findBySubItemsContaining(String subItem), but does not allow findBySubItemsNotContaining(String subItem).

NOT_CONTAINING keyword is not part of the Part.Type enum.
Was it not included for specific reason or was just missed out ?

It's affecting directly Spring Data DynamoDB implementation

---

Issue Links:

• DATAJPA-618 Pay attention to collection like properties when creating containing queries from part tree

• DATAMONGO-1075 Correctly evaluate CONTAINS keyword on collection properties

Referenced from: pull request #100

[spring-projects-issues]

Thomas Darimont commented

Hello Sergio,

I gave this a quick look. Yes you are right, we currently don't support the NotContaining expression part.
After adding the necessary bits to SD Commons and SD JPA [0] to try it out, I was able to define queries like:

List<User> users = repository.findAllByFirstnameNotContaining("%li%");

Internally I mapped the functionality to the like expressions and then I wondered whether we should support this at all since
can already express that functionality via firstnameNotLike(....).

How would you expect it to work different than the like expression?

Cheers,
Thomas

[0] https://gist.github.com/thomasdarimont/9303fcdabaa84f5e7b3c

[spring-projects-issues]

Sergio Correa commented

Hi Thomas,

Actually, this issue came up when I tried to use {NotContaining} expression with Spring-Data DynamoDB, which also does not support the expression since it relies on SD Commons. Discussing with the responsible for Spring-Data DynamoDB explained me this change is required in order to add support for {NotContaining} expression.

I see your point when you say {like} expression would meet the needs, but then Spring-Data DynamoDB or any future framework would have to interpret {NotLike} as the common behaviour for the expected {NotContaining} expression.

For me, it would not make any difference and I would get the final result as expected. I just wonder how confusing it could be for frameworks extending SD Commons.

For instance, DynamoDB supports CONTAINS and NOT_CONTAINS. It would just be a matter of mapping the expressions.

I hope my explanation is understandable and plausible.

Cheers,
Sergio

[spring-projects-issues]

Michael Lavelle commented

Hi Thomas

I've been watching this issue which I understand arose because Sergio would like to use NotContaining with the Spring Data DynamoDB project in order to support queries on entities with set properties. I just wanted to add this detail, because in the discussion about whether NOT_LIKE can be used in your reply above, I think you were thinking the requirement was to search for entities with string property values not containing a keyword, whereas in fact the requirement is to search for entities where a set property doesn't contain an element.

Hope this makes sense,

Cheers,

Michael

[spring-projects-issues]

Thomas Darimont commented

Hi Michael, Hi Sergio,

thanks for clarification :) Indeed I thought you wanted to use it to check whether a string contains another string...
The above PR would add support for the discovery of the "NotContaining" keyword and variants.

Regarding the element containment test, I wonder whether this isn't already covered by:

List<User> findByFirstnameNotIn(Collection<String> firstnames);

and could be translated accordingly in DynamoDB or is there a different meaning there?

Cheers,
Thomas

[spring-projects-issues]

Sergio Correa commented

Hi Thomas,

Actually what we need is to check if a Collection<String> field contains or not an element.
In your example it checks if the field value is contained in a Collection<String> argument.

For instance:

List<String> findByTagsContaining(String tag);

Tags is defined as Set<String>.

Cheers,
Sergio

[spring-projects-issues]

Thomas Darimont commented

Hello Sergio,

sorry again for the confusion :) Currently the contains keyword just used for searching in strings (in JPA, Mongo, etc.), hence the confusion...
By looking at your implementation [1] I just learnt that dynamodb's ComparisonOperator.CONTAINS [0] is context aware and works with strings as well as collections (sets).

This could be something that we could add for the other stores as well. This would mean that we would need to check the property type in the various QueryCreator implementations for CONTAINING and NOT_CONTAINING and generate appropriate membership tests in case the property type is collection like.

In the above mentioned PR, I just added support for the NotContaining keyword combination to SD Commons,
so this should be enough for you to support this use case. Maybe Oliver Drotbohm can have a look at this as well.

Cheers,
Thomas

[0] - http://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html
[1] - https://github.com/michaellavelle/spring-data-dynamodb/blob/master/src/main/java/org/socialsignin/spring/data/dynamodb/repository/query/AbstractDynamoDBQueryCreator.java#L95

[spring-projects-issues]

Sergio Correa commented

Hi Thomas,

Thank you for your collaboration.
Now Michael has to add the same support in Spring Data DynamoDB.

Cheers,
Sergio

[spring-projects-issues]

Thomas Darimont commented

Please revise