Problem using forklift with VCS about scala-forklift

[lastland]

Hi, the reason is that all the migration objects must be executed somewhere. I put them in MigrationSummary so they can be executed when MigrationSummary is executed (and MigrationSummary will be executed by MyMigrations).

I think the best solution is to have the empty MigrationSummary in your version control but never commit any changes to it. I'm not familiar with Mercurial. Do you think there is an easy way to do that in Mercurial?

[alexkvak]

Thanks for answer, I need to try it.
I have one more idea, write soon.

[alexkvak]

The problem is that we have rolled migrations summary. But we need to have all available migrations in summary and look for their status through the database. In this case we don't need to create symlinks and can commit all changes.
If I could change the migration status source, it would be enough for my case. Could you help me to find the respective code?

[lastland]

I'm glad to help. However, I'm not sure I have understood your question.

I would not recommend putting the rolled migrations and migration summary in your version control, because some migrations may depend on the generated code, which may not have been generated on other people's machine.

[alexkvak]

Ok, let me explain one more time.
I need to easy deploy an application and run tests on teamcity. So, code must be compiled every time. MyMigrations depends on MigrationSummary which contains for now only rolled migrations. I would like to store in MigrationSummary all available migrations. On other hand the status of migrations stored in database, and it's completely enough.

What do you think?

[lastland]

If you store all migrations in MigrationSummary you might not be able to compile the code because the code might depend on some generated code which is not generated yet.

If you want to get the status of migrations stored in the database, you can find it out using this method. If you want to modify how migration files and migration summary are handled, you can try to override traits in this file(In particular, handleMigrationFiles for creating symlinks for migration files; writeSummary for putting migrations into the summary file).

[lastland]

I think I might see a problem here. If you compile and run a clean copy of the code on a machine with some migrations already applied, there might be a problem: the migrations will not be applied twice, but Forklift will not generate code for current database schemas, either. Not sure if that's a problem you have met. I will try to find some time to fix that over the weekend.

[alexkvak]

If you store all migrations in MigrationSummary you might not be able to compile the code because the code might depend on some generated code which is not generated yet.

If I deploy the project from scratch I might meet the same problem. So it's the problem of migration code, but not MigrationSummary file.
We should always store the actual DB schema and migration list in repository. It guarantees us always working code.

[alexkvak]

I overriden handleMigrationFile method, I don't create symlink, but make a hard copy of migration file. In this case application always compiles well.

[lastland]

Cool! Guess I should make hard copy an option.

[lastland]

Should be fixed by #35