1192 Query by Example (6/7)

[DiegoKrupitza]

In this PR I implemented 6 out of the 7 methods from QueryByExampleExecutor. Due to my missing knowledge of MyBatis the implementation MyBatisDataAccessStrategy of DataAccessStrategy currently throws UnsupportedOperationException. I hope there is someone who could implement this who has a better insight into MyBatis.

One method (see below) is not implemented, since I can't see what exactly I should implement here. I also hope someone could implement this so we have full "Query By Example" support.

The following methods are now implemented:

• Optional<S> findOne(Example<S> example);
• Iterable<S> findAll(Example<S> example);
• Iterable<S> findAll(Example<S> example, Sort sort);
• Page<S> findAll(Example<S> example, Pageable pageable);
• long count(Example<S> example);
• boolean exists(Example<S> example);

Missing implementation:

• findBy(Example<S> example, Function<FetchableFluentQuery<S>, R> queryFunction);

PS: I hope the formatting is now correct (I reconfigured it)

(Partially) Closes #1192

• You have read the Spring Data contribution guidelines.
• You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.
• You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

[schauder]

Thanks for the PR.

As for MyBatis: I'd say we can start without MyBatis support.
But if we implement it we should look for query parts that we can assemble using MyBatis into the full query.

As for findBy(Example<S> example, Function<FetchableFluentQuery<S>, R> queryFunction);
There is an implementation in SD JPA for this: https://github.com/spring-projects/spring-data-jpa/blob/47e2423612b2410ec284d1cb048d5a8815a705f3/spring-data-jpa/src/main/java/org/springframework/data/jpa/repository/support/SimpleJpaRepository.java#L499

Maybe with this as a basis you can add the implementation for JDBC as well?

As to the PR: We shouldn't drag the Example abstraction into the JdbcAggregateTemplate. Instead we should pass a Criteria into methods that then perform as select/count/exists query based on that criteria.

There is alread a QueryMapper which gets used by derived queries, which unfortunately currently side steps the JdbcAggregateTemplate if I remember correctly.

[DiegoKrupitza]

As for MyBatis: I'd say we can start without MyBatis support

ok sounds good to me. After this PR is completed I can open an new issue for the MyBatis implementation.

As for findBy(Example<S> example, Function<FetchableFluentQuery<S>, R> queryFunction);
There is an implementation in SD JPA for this:

Ok I will take a closer look at this.

We shouldn't drag the Example abstraction into the JdbcAggregateTemplate. Instead we should pass a Criteria into methods that then perform as select/count/exists query based on that criteria.

The main reason why I did that was that people who might use JdbcAggregateTemplate directly still can benefit from the abstraction. Additionally it was easier to create a RelationalExampleMapper object within JdbcAggregateTemplate than inside SimpleJdbcRepository, since I could not see a way to get a RelationalMappingContext in SimpleJdbcRepository.

There is alread a QueryMapper which gets used by derived queries, which unfortunately currently side steps the JdbcAggregateTemplate if I remember correctly.

Yeah I am already using the QueryMapper you are mentioning in SqlGenerator. To do so I had to make certain methods public since they were package-private.

@schauder

PS: I can't promise when I can continue working on this PR since right now I have a lot to do for Uni, but I hope I can find some time here and there

[DiegoKrupitza]

@schauder Why was there a force push from the main?

[schauder]

@DiegoKrupitza We turned the old main into 2.7.x and 3.0.x became the new main.

Sorry for the confusion.

[DiegoKrupitza]

@schauder I resolved all the merge conflicts and triggered a mvn clean test to check that I did not break anything.
Two tests are failing:

• org.springframework.data.jdbc.core.convert.InsertStrategyFactoryTest: has nothing to do with my code (I assume this is also why the CI currently fails)
• org.springframework.data.jdbc.DependencyTests.cycleFree(): this tests fails since inside the SqlGenerator (from package core.convert) I am using the QueryMapper (package repository.query) to convert the Criteria condition to a WHERE condition. QueryMapper has some quite sophisticated logic that is really needed inside the SqlGenerator. The ONLY other location that uses QueryMapper is JdbcQueryCreator (package repository.query) and this is why the cycleFree() test fails. JdbcQueryCreator uses classes from package core.converter. The circle is Cycle detected: Slice core.convert -> Slice repository.query -> Slice core.convert. Rewriting the Cirteria to SqlWhere condition just for the SQLGenerator class would not make sense since this logic is already implemented somewhere.

Can you recommend what I can do against the two failing tests?

[schauder]

Thanks, that's merged.