Support of query derivation

[rchigvintsev]

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?

[mp911de]

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.

[rchigvintsev]

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: PartTree-based implementation of AbstractR2dbcQuery and query generation using classes from spring-data-relational.

For now I don't understand how spring-data-jdbc and spring-data-r2dbc are going to be in sync. Classes like AbstractJdbcRepositoryQuery or JdbcQueryCreator should obviously be project-specific. Is synchronization only related to features that will be added to spring-data-relational and spring-data-commons projects?

[mp911de]

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.

[rchigvintsev]

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?

[mp911de]

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.

[schauder]

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?

[mp911de]

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.

[rchigvintsev]

@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.

[schauder]

@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.

[rchigvintsev]

@schauder OK, I will try to prepare basic solution as soon as possible.

[rchigvintsev]

PR: #295