[WIP] Add control options to override and/or validate index file #150
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello Rob, we would like to have some options to override how and if the idx file is used.
We have two use cases:
As far as I understand the code, the checksum is never calculated or verified at run time. (This means, I can edit SQL files without getting problems, or when merging two branches)
So the
setForceLocalCheck = true
option in the build pipeline, will ensure, that the checksum in idx file will match to the contentImagine, you have a migration in 1.1 where you want to convert everything in a table to uppercase, So we have in /src/main the standard migrations:
create table foo(varchar(32) name)
)update foo set name = ucase(name)
)When we verify the migrations in some unit tests, we run them on an empty database. To get data in the DB, we "insert" some scripts in /src/test
insert into foo values ('Roland')
)Prior #91 - ebean migration discovered all migrations in the classpath and has executed
A java assert can then check, if everything is properly migrated.
(Note: The conversion to uppercase was just an example. In real life, we have much more complex migrations.)
This PR would help us to cover both use cases (while use case 2 is more important than 1)