Skip to content

DATACOUCH-652 - Inject translation service bean in CouchbaseTemplateSupport. #294

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

Conversation

jorgerod
Copy link
Contributor

@jorgerod jorgerod commented Dec 14, 2020

DATACOUCH-652

TranslationService is defined as bean but in CouchbaseTemplateSupport.
That bean is not being used and a new instance of JacksonTranslationSerivce is being created in the constructor.

We want CouchbaseTemplateSupport to receive a TranslationService type bean.

  • You have read the Spring Data contribution guidelines.
  • There is a ticket in the bug tracker for the project in our JIRA.
  • 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).

@pivotal-issuemaster
Copy link

@jorgerod Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

@pivotal-issuemaster
Copy link

@jorgerod Thank you for signing the Contributor License Agreement!

@mikereiche
Copy link
Collaborator

This looks good to me. I'm adding another reviewer.

@mikereiche mikereiche changed the title DATACOUCH-652 - Inject translation service bean in CouchbaseTemplateSuppot DATACOUCH-652 - Inject translation service bean in CouchbaseTemplateSupport Dec 16, 2020
@jorgerod
Copy link
Contributor Author

Hi @mikereiche @daschl

I think it would be interesting to make a backport to 4.1.x.

How do you see it?

@@ -145,14 +146,14 @@ protected void configureEnvironment(final ClusterEnvironment.Builder builder) {

@Bean(name = BeanNames.COUCHBASE_TEMPLATE)
public CouchbaseTemplate couchbaseTemplate(CouchbaseClientFactory couchbaseClientFactory,
MappingCouchbaseConverter mappingCouchbaseConverter) {
return new CouchbaseTemplate(couchbaseClientFactory, mappingCouchbaseConverter);
MappingCouchbaseConverter mappingCouchbaseConverter, TranslationService translationService) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this breaks backwards compatibility by introducing another required argument - if this should be added we need another overload that keeps the defaults as is I think

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @daschl

You are right about the overloading of the CouchbaseTemplate and ReactiveCouchbaseTemplate constructors. I'll update it now.

As for the definition of beans couchbaseTemplate and reactiveCouchbaseTemplate, do you consider any change necessary? I didn't quite understand you.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I was actually also talking about the bean definitions - because if someone overloads them in their actual configuration, just changing the signature on update will fail to compile for them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @daschl

It's true that is a breaking change, but I can't think of any other way to do it. Bean couchbaseTranslateService is being created but then not used.

If you don't want to be breakers, we could keep the overload on the CouchbaseTemplate and ReactiveCouchbaseTemplate constructors and at another time add the TranslationService parameter to the configuration beans and then be breakers.

What do you think?

Thank you very much

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jorgerod well, you could make the beans take the new parameter by default (as you do now), but add another 2 methods that look like the old signature and not be a Bean, which call into the new beans and just initialize the json translation service. Then if someone overrides it, their code would not break but everyone can then switch over to the new bean if needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand. Thank you very much for the help @daschl

Copy link
Contributor

@daschl daschl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this contains a breaking change as-is

@@ -145,14 +146,14 @@ protected void configureEnvironment(final ClusterEnvironment.Builder builder) {

@Bean(name = BeanNames.COUCHBASE_TEMPLATE)
public CouchbaseTemplate couchbaseTemplate(CouchbaseClientFactory couchbaseClientFactory,
MappingCouchbaseConverter mappingCouchbaseConverter) {
return new CouchbaseTemplate(couchbaseClientFactory, mappingCouchbaseConverter);
MappingCouchbaseConverter mappingCouchbaseConverter, TranslationService translationService) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The translationService argument should be named couchbaseTranslationService to match the bean name.
When the argument name does not match the bean name, the spring framework can only match by the type, and if there is ever another bean of type TranslationService added, the spring framework will not be able to automatically match this argument with the couchbaseTranslationService bean.

@mikereiche
Copy link
Collaborator

@jorgerod - Please put a period at the end of the first line of the commit message. (they are parsed programmatically) Thanks.

DATACOUCH-652 - Inject translation service bean in CouchbaseTemplateSupport

@jorgerod jorgerod changed the title DATACOUCH-652 - Inject translation service bean in CouchbaseTemplateSupport DATACOUCH-652 - Inject translation service bean in CouchbaseTemplateSupport. Dec 18, 2020
@jorgerod
Copy link
Contributor Author

@jorgerod - Please put a period at the end of the first line of the commit message. (they are parsed programmatically) Thanks.

DATACOUCH-652 - Inject translation service bean in CouchbaseTemplateSupport

Hi @mikereiche

I've checked the commit messages and they all have a period at the end of the line.

@jorgerod
Copy link
Contributor Author

Hello @daschl @mikereiche

Have you been able to see the latest updates?

Greetings

@mikereiche
Copy link
Collaborator

@jorgerod - can you resolve the conflicts? Then I will merge this.

@jorgerod
Copy link
Contributor Author

@mikereiche Conflicts resolved.

@mp911de
Copy link
Member

mp911de commented Jan 15, 2021

@jorgerod please squash your commits into a single one as we keep a single commit (and a linear history) per change.

@jorgerod jorgerod force-pushed the datacouch_652_inject_bean_translator_service_to_couchbase_template_support branch from 51ca98a to 074b454 Compare January 15, 2021 11:38
@jorgerod
Copy link
Contributor Author

Hi @mp911de

I have already squashes my commits. Does it look good?

Thank you

@mikereiche mikereiche merged commit 1329cae into spring-projects:master Jan 15, 2021
@jorgerod
Copy link
Contributor Author

Hi @mikereiche @daschl

I think it would be interesting to make a backport to 4.1.x.

How do you see it?

Hi @mikereiche

How does it look?

@jorgerod jorgerod deleted the datacouch_652_inject_bean_translator_service_to_couchbase_template_support branch January 18, 2021 08:12
@mikereiche
Copy link
Collaborator

It will be in the next 4.1.x release scheduled for February 10.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-triage An issue we've not yet triaged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants