-
Notifications
You must be signed in to change notification settings - Fork 306
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
DefaultTaskConfigurer constructors should use TaskProperties.getTablePrefix() instead of constant TaskProperties.DEFAULT_TABLE_PREFIX #939
Comments
Thank you for the comment and good catch on the |
Because if we want to customize only one argument then we don't have to deal with and research internal mechanisms for table prefix Think somebody that just wants to pass a custom datasource, then he performs
But then he realises that the tables are being created in another place (when using latest SpringBoot3-enabled SCDF, for instance), he or she needs to research the implementation and understand that you need to reproduce the previous default
It's an undersirable side-effect, because you are extending DefaultTaskConfigurer, so everything yoo don't explicitly touch, should remain as the Default configuration according to the name Indeed ideally IMO it should be something like
|
Let's see If we can squeeze this into 3.1.2 |
Since this is a change in behavior this will be in the 3.2 release of Task. |
Can you provide any rough estimation whatsoever for when that may be released so I can update our Jira with more information? For now, the story is flagged in the current sprint (2 weeks remaining for it) but if 3.2 won't be coming for some time I'd rather push it back to the backlog. |
I'm looking at giving the user the ability to pass in a TaskProperties into the constructor and then letting the DefaultTaskConfiguration constructor resolve tablePrefix as @nightswimmings suggested above. Since this solution doesn't affect the default behavior I can put it back onto the 3.1.2 release. |
This has been pushed to 3.2, based on discussions that a change like this can't be put into a patch release. |
Thanks for the update. I'll wait patiently, no problem. Plenty of other things on our backlog that need doing. |
Rebased Merged |
Right now if one uses DefaultTaskConfigurer without specifying a prefix, it looses the ability to use the one from properties.
I think when not passed as a param, it should use TaskProperties.getTablePrefix() and instead set the default at the TaskProperties level
Besides, shouldn't "Class.forName("javax.persistence.EntityManager");" be now "Class.forName("jakarta.persistence.EntityManager");" considering this corresponds to the release train for Boot 3.2?
The text was updated successfully, but these errors were encountered: