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

Allow instantiation using builders [DATACMNS-1397] #1832

Closed
spring-projects-issues opened this issue Sep 26, 2018 · 6 comments
Closed

Allow instantiation using builders [DATACMNS-1397] #1832

spring-projects-issues opened this issue Sep 26, 2018 · 6 comments
Assignees
Labels
in: mapping type: enhancement

Comments

@spring-projects-issues
Copy link

spring-projects-issues commented Sep 26, 2018

Jan Rieke opened DATACMNS-1397 and commented

With DATACMNS-1322, Spring Data took a step forward towards better support for immutable objects using withers. However, if you have to set a larger number of fields, using withers has the drawback that you create a new instance on every wither call.

Of course you could use "the traditional way" for instantiating immutable objects: a constructor with all fields as parameters. Lombok's @AllArgsConstructor is typically used to avoid writing those boilerplate constructors.
However, in our case, we have a class hierarchy for our model classes. It is typically 1 to 3 classes deep, and every superclass has its own properties. Because Lombok's @AllArgsConstructor does not include the fields from superclasses (and probably will not in the foreseeable future), we have to manually implement an all-args constructor for every model class. This approach is quite error-prone, because when new fields are added to a superclass, you have to manually alter the constructors of all subclasses.

Recently, Lombok added the @SuperBuilder feature, which significantly improves the applicability of builders in such a case, because a @SuperBuilder includes setters for fields from superclasses. It would be extremely useful if we could advise Spring Data to use such a builder when creating instances. Then we could completely remove the (manual) all-args constructors.

Jackson, for instance, takes such an approach; you can use the annotations @JsonDeserialize and @JsonPOJOBuilder to tell Jackson to use the builder to construct the instance


No further details from DATACMNS-1397

@spring-projects-issues spring-projects-issues added type: enhancement in: mapping labels Dec 30, 2020
@JohannesPertl
Copy link

JohannesPertl commented Jun 22, 2022

This is a huge issue, yet doesn't seem to get much attention. Any updates?

@odrotbohm odrotbohm added the status: waiting-for-feedback label Jun 23, 2022
@odrotbohm
Copy link
Member

odrotbohm commented Jun 23, 2022

Can you elaborate why you think it's a huge issue? Builders are primarily a developer convenience, both to at writing and reading time. Spring Data object instantiation is none of that. There already is an EntityInstantiator API that allows customizing the construction based on the persistence constructor's parameters. Also, there's CustomConversions, which – through its store-specific extensions – allows registering Spring Converter instances that would even allow you to take care of the entire object instance creation and population explicitly.

@JohannesPertl
Copy link

JohannesPertl commented Jun 23, 2022

As the original poster described: Basically @AllArgsConstructor, a fundamental functionality of Lombok, needs @SuperBuilder to also work with super classes.

@spring-projects-issues spring-projects-issues added status: feedback-provided and removed status: waiting-for-feedback labels Jun 23, 2022
@odrotbohm
Copy link
Member

odrotbohm commented Jun 23, 2022

How far developers mitigate challenges with their object model using Lombok doesn't really play into design decisions in Spring Data.

I was actually referring to the implied severity of the report. "Huge issue" implies that either many users are affected or there's a fundamental problem with no suitable workarounds available. I don't see either of the two. Which means we are essentially back to a discussion about whether the available means to deal with this challenge are enough, and, if not, what additional complexity in the object mapping would be justified to solve an issue that doesn't seem that pressing. The ticket hasn't seen any significant feedback for four years.

I think it makes sense to evaluate how far the already existing APIs pointed to above help mitigate the problem and take it from there, potentially having an example in which challenges with the suggest approaches are described for further evaluation.

@odrotbohm odrotbohm added status: waiting-for-feedback and removed status: feedback-provided labels Jun 23, 2022
@spring-projects-issues
Copy link
Author

spring-projects-issues commented Jun 30, 2022

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

@spring-projects-issues spring-projects-issues added the status: feedback-reminder label Jun 30, 2022
@spring-projects-issues
Copy link
Author

spring-projects-issues commented Jul 7, 2022

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

@spring-projects-issues spring-projects-issues removed status: waiting-for-feedback status: feedback-reminder labels Jul 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: mapping type: enhancement
Projects
None yet
Development

No branches or pull requests

3 participants