-
Notifications
You must be signed in to change notification settings - Fork 132
Support of query derivation #282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for reaching out. We want to add query derivation to Spring Data R2DBC. We're currently in the planning so we can add query derivation to both projects, Spring Data JDBC and R2DBC to keep both projects in sync, time- and feature-wise. Check out the corresponding ticket DATAJDBC-318. |
I've made a quick look at James Clark's solution (from discussion in ticket it seems like a major solution) and compared it with mine. My approach is similar: For now I don't understand how spring-data-jdbc and spring-data-r2dbc are going to be in sync. Classes like |
The synchronization is mostly to keep both SQL-based projects on the same level of functionality (i.e. timing-wise and what the query derivation is capable of). Paging @schauder as Jens is involved already in Spring Data JDBC. I'm not sure, probably the only thing that is holding us from building query derivation in Spring Data JDBC is the required dialect support. |
OK. Thanks for clarification! But I still don't see an answer to the question that I asked above: is it worth for me to keep going and provide a PR or you are going to wait for finishing of DATAJDBC-318 and then adopt it to this project? |
Probably it makes the most sense that a single contributor takes care of both changes. Alternatively, we can move forward with R2DBC and adapt that functionality in JDBC as it seems that we can make more progress with Spring Data R2DBC right now. |
The situation of DATAJDBC-318 is a little unfortunate, since there exist two solutions but no proper PR and I did not get a reply on my request to receive such a PR. If you @rchigvintsev would provide a PR for DATAJDBC-318 I (and maybe @mp911de ) would review it in a timely fashion. And once that is done we could move forward and port it to Spring Data R2DBC. How does that sound for a plan? |
I think porting works either way. Either from JDBC to R2DBC or vice versa. In any case, I like the idea and I'm happy that we can progress here. |
@schauder For me it is easer to stick to R2DBC (since I've already done some work on this feature) and provide a PR here possibly looking at the solutions from DATAJDBC-318 to make future porting simpler. On the other side single contributor is definitely a good option and it seems like work on DATAJDBC-318 is almost done. |
@rchigvintsev then please go ahead and create a proper PR for R2DBC. DATAJDBC is in an unhealthy state right now as I tried to explain above. |
@schauder OK, I will try to prepare basic solution as soon as possible. |
PR: #295 |
…o be able to build SQL manually
…GATING_SIMPLE_PROPERTY' conditions
…'NOT CONTAINING' condition
…ery' for 'PartTreeR2dbcQuery'
…ry explicitly associated with repository method
…ntation of 'io.r2dbc.spi.Statement' may not support binding
…rmatting settings
…es in Spring Data Relational
… whether parameter is scalar
… instead of 'StatementBuilder'
… instead of 'StatementBuilder'
We now support query derivation for R2DBC repositories: interface ReactivePersonRepository extends ReactiveSortingRepository<Person, String> { Flux<Person> findByFirstname(String firstname); Flux<Person> findByFirstname(Publisher<String> firstname); Mono<Person> findByFirstnameAndLastname(String firstname, String lastname); Flux<Person> findFirstByLastnameLike(String pattern); } Original pull request: #295.
Move query derivation infrastructure to Spring Data Relational. Adapt to newly introduced ValueFunction for deferred value mapping. Use query derivation in integration tests. Tweak javadoc, add since and author tags, reformat code. Related ticket: https://jira.spring.io/browse/DATAJDBC-514 Original pull request: #295.
The PR is merged now. |
I have a simple conceptual implementation of query derivation partly based on corresponding code in spring-data-jpa and Hibernate projects. For now it looks a bit messy and needs to be put in order. I could clean the code, write several test and then create a pull request so you could review a solution.
Is it worth doing or you guys are already in the middle of developing such feature?
The text was updated successfully, but these errors were encountered: