Skip to content
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

Provide better integration & docs (for manual joins) #439

Closed
pmaedel opened this issue Sep 2, 2020 · 4 comments
Closed

Provide better integration & docs (for manual joins) #439

pmaedel opened this issue Sep 2, 2020 · 4 comments
Labels
status: waiting-for-feedback We need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged

Comments

@pmaedel
Copy link

pmaedel commented Sep 2, 2020

I successfully integrated joins manually with data r2dbc while utilizing the r2dbc mapping and have a couple of issues I would like to discuss.

Please see the example project here

1. It should be documented that R2dbcConverter must be obtained through ReactiveDataAccessStrategy
The docs state that R2dbcConverter is recommended to do most of the work. R2dbcConverter however must be obtained via ReactiveDataAccessStrategy. This is fine, but should be documented, as I did expect R2dbcConverter to be readily available as a Bean when being so heavily advertised.

2. R2dbcConverter should provide read functionality that accepts alias prefixes for columns
Please see this example.
I can easily map the root entity (tree) via read(type, row, rowMetadata). Mapping the aliased joined entity (fruit) however seems only to be possible by hacking a customized read functionality, which would better be provided via R2dbcConverter. I have seen that prefixes are available internally but could not find a way to use them for my use case.

3. Spring Data Repository Customization override priority is not working as documented
The docs state that Custom implementations have a higher priority than the base implementation and repository aspects. This ordering lets you override base repository and aspect methods and resolves ambiguity if two fragments contribute the same method signature.. This test shows, that overrides only occur when the parameter type of the override is made available to the custom implementation via generics. A matching signature without generics does not result in an override.

4. Please find out whether a separate persistence constructor is really necessary when using transient fields (with default values) in Kotlin data classes
Here I made the joined Entity available as a transient field. The necessity to provide a separate persistence constructor seems odd to me, as I would think it should be possible to exclude a @Transient field during mapping for which default value is defined?

@mp911de
Copy link
Member

mp911de commented Sep 7, 2020

Care to carve out each item into its own issue? Otherwise, it will be next to impossible to have an ordered discussion.

@mp911de mp911de added status: waiting-for-feedback We need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged labels Sep 7, 2020
@pmaedel
Copy link
Author

pmaedel commented Sep 7, 2020

Sure, maybe you could give me a pointer into which projects the separate issues should be (re)created?

@mp911de
Copy link
Member

mp911de commented Sep 7, 2020

This is already the right project for 1, 2, and 4. 3. can go to Stack Overflow as this is a good question to be shared with the community.

Please make sure to attach a bit of code to the tickets as external links can easily point to 404's and so the context of a ticket gets lost.

@pmaedel pmaedel closed this as completed Sep 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-feedback We need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged
Projects
None yet
Development

No branches or pull requests

2 participants