-
Notifications
You must be signed in to change notification settings - Fork 77
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
Add EnvironmentLoader to customize how Migrations loads environment settings. #128
Conversation
Hi @harawata! Sorry I've been busy and meant to do the work for this myself. I was thinking something more simple on the lines of Resources or as described on ResolverUtil. This allows me to create and distribute a jar that can both up and down migrations for multiple environments. I see the benefit of your approach is that you can load from any resources even a central config server so that's pretty neat in itself. |
I see.
It is flexible for sure, but it also feels like a little bit too over-engineered. |
@harawata sorry for the late review. Order of checking would go |
FYI I made the style/code consistency changes already if you want me to push those up to a shared branch? Just to save some time. |
I would be happy to take a look at your approach if it's simpler.
Sure, you can push directly to my branch, right? |
I think so. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works well with what I had (I can refactor that to use this style) if we did it that way I think.
I would be happy to take a look at your approach if it's simpler.
I am still not sure if this level of flexibility is necessary, to be honest.
I'll add the changes on top of yours.
if you want me to push those up to a shared branch? Just to save some time.
Sure, you can push directly to my branch, right?
I cant seem to push to your branch so I pushed to a same named branch on origin
environment = new Environment(existingEnvironmentFile()); | ||
EnvironmentLoader envLoader = null; | ||
for (EnvironmentLoader found : ServiceLoader.load(EnvironmentLoader.class)) { | ||
if (envLoader != null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should allow multiple loaders using some default fallbacks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any example use case of multiple loaders?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I meant this to be from 213-222.
So removing the null check on 220 and adding their custom loader on top of set default ones (similar to spring properties resolver).
I am changing lines 220-223 to add my environment and system properties loaders.
@@ -43,7 +43,8 @@ public void execute(String... params) { | |||
createDirectoryIfNecessary(paths.getDriverPath()); | |||
|
|||
copyResourceTo("org/apache/ibatis/migration/template_README", Util.file(basePath, "README")); | |||
copyResourceTo("org/apache/ibatis/migration/template_environment.properties", environmentFile()); | |||
copyResourceTo("org/apache/ibatis/migration/template_environment.properties", | |||
new File(paths.getEnvPath(), options.getEnvironment() + ".properties")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a code consistency here. but envpath
can be extracted.
also the rest use util.file (which can really just be changed to what you have here File(parent, file)
or removed)
@@ -43,7 +43,8 @@ public void execute(String... params) { | |||
createDirectoryIfNecessary(paths.getDriverPath()); | |||
|
|||
copyResourceTo("org/apache/ibatis/migration/template_README", Util.file(basePath, "README")); | |||
copyResourceTo("org/apache/ibatis/migration/template_environment.properties", environmentFile()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this method isn't used anymore. nor the supporting existingEnvironmentFile
hook_after_new | ||
} | ||
|
||
protected static final List<String> SETTING_KEYS; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
private
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought that users might create a custom loader by subclassing this built-in one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah that makes sense but I think if that's the case we should move this to something common.
This is the keys though, it is an implementation detail that we have changed before so depending on it might not be a good idea
protected Properties readProperties(String environmentName, SelectedPaths paths) { | ||
File file = new File(paths.getEnvPath(), environmentName + ".properties"); | ||
FileInputStream inputStream = null; | ||
try { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can be replaced with try with resources
Properties prop = new Properties(); | ||
prop.load(inputStream); | ||
return prop; | ||
} catch (FileNotFoundException e) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this just be logged warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a user specified --env=someenv
and there is no someenv.properties
, throwing an exception seems appropriate.
What kind of use case are you thinking about?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, you want Migrations to work even if there is no .properties file, am I right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup! I'm ok either way since there's a default one that's added during init.
So it's not a big deal. more for flexibility
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's a good idea.
We can, for example, ignore FileNotFoundException
only when the environmentName
is "development"
.
Can this be closed now @harawata? |
@h3adache , |
There has been a few requests for alternative methods to configure environment settings (#90 , #122).
This PR adds a new interface
EnvironmentLoader
.Migrations looks for its implementation via Java SPI at runtime (similarly to #107).
@h3adache ,
I do not fully understand how you use Migrations, so please take a look and see if it meets the requirements (no rush, of course).
Here is the implementation that I used to test.
I'll add documentation if you approve the change.