search

dradovic / MigSharp

Mig# (MigSharp) is a .NET framework for database migrations and versioning
Other
106 stars 34 forks source link

Ability to get the actual schema version #25

Closed balistof closed 12 years ago

balistof commented 13 years ago

For our application we need to inform the user about the current version of his database schema and ask him if he wants to upgrade or not. I know that the version is on a per module basis and that it leaves out potential gaps in the migrations (not all migrations applied). But that is of a different story since some migrations are based on prior executed migrations. Would that be a feature to include?

dradovic commented 13 years ago

So, what you currently have is the method Migrator.IsUpToDate(). We use it exactly for this purpose. To give the user feedback that migrations are pending. The exact timestamp(s) that are missing should be transparent to the user in my opinion.

balistof commented 13 years ago

What the Migrator.IsUpToDate() method does not tell me if the database is on a newer version than the application itself.

In my project we have to deal with both cases. One is the older database then required by the application. So there the IsUpToDate() method is fine. But the second case is when the required database version is lower than the actual one.

On Tue, Aug 30, 2011 at 8:08 PM, dradovic < reply@reply.github.com>wrote:

So, what you currently have is the method Migrator.IsUpToDate(). We use it exactly for this purpose. To give the user feedback that migrations are pending. The exact timestamp(s) that are missing should be transparent to the user in my opinion.

Reply to this email directly or view it on GitHub: https://github.com/dradovic/MigSharp/issues/25#issuecomment-1946427

dradovic commented 13 years ago

I see. You are right. There are four possible states we could be at:

  1. The database and the application are in-sync (all available migrations are run).
  2. The database is out of-date (there are pending migrations).
  3. The application is out-of-date (there are executed migrations which the application does not know of).
  4. Both the database and the application are out-of-date (2+3). I guess, we need a method that tells us in which state we are. And IsUpToDate() would become a special case of that more general method. What do you think?
balistof commented 13 years ago

Yes, I could live with that! As a user I would like to see what is going on with back-end data.

dradovic commented 13 years ago

Why did you close the issue? We haven't programmed it yet... :)

balistof commented 13 years ago

Ups, was not my intention.... I guess to early in the morning ;)

dradovic commented 13 years ago

So, my suggestion is as follows:

  1. Let's mark the IsUpToDate method as obsolete. People should use the new technique to get that information. IsUpToDate tells you only half of the truth and therefore is dangerous.
  2. To prevent more than one round-trip to the database, the FetchMigrations and FetchMigrationsTo methods should already return the complete information about pending and unknown migrations (by "unknown", I mean migrations that are in the database but are not found in the application). A nice design would dictate, that these methods would return something else than IMigrationBatch - some interface that tells you the state (UpToDate/PendingMigrations/UnknownMigrations) and also gives you the possibility to execute the pending migrations (in the form of an IMigrationBatch). See also issue #27. But this would mean that the API would not stay backward compatible and therefore we can only do it in v2. In the meantime, for v1.x, I suggest to extend the IMigrationBatch interface with a boolean flag (yay) that tells if there were any unknown migrations, something like UnknownMigrationsDetected. This flag would tell you if your application is out-dated and it will be removed again in v2.

Is this something you could live with for now?

balistof commented 13 years ago

Yes, that sounds good to me!

Thanks, Chris

On Wed, Sep 7, 2011 at 7:21 AM, dradovic < reply@reply.github.com>wrote:

So, my suggestion is as follows:

  1. Let's mark the IsUpToDate method as obsolete. People should use the new technique to get that information. IsUpToDate tells you only half of the truth and therefore is dangerous.
  2. To prevent more than one round-trip to the database, the FetchMigrations and FetchMigrationsTo methods should already return the complete information about pending and unknown migrations (by "unknown", I mean migrations that are in the database but are not found in the application). A nice design would dictate, that these methods would return something else than IMigrationBatch - some interface that tells you the state (UpToDate/PendingMigrations/UnknownMigrations) and also gives you the possibility to execute the pending migrations (in the form of an IMigrationBatch). But this would mean that the API would not stay backward compatible and therefore we can only do it in v2. In the meantime, for v1.x, I suggest to extend the IMigrationBatch interface with a boolean flag (yay) that tells if there were any unknown migrations, something like UnknownMigrationsDetected. This flag would tell you if your application is out-dated and it will be removed again in v2.

Is this something you could live with for now?

Reply to this email directly or view it on GitHub: https://github.com/dradovic/MigSharp/issues/25#issuecomment-2025710

dradovic commented 13 years ago

I've just committed a first draft of this feature. It will be contained in v2.0. Please have a look if the new API satisfies your needs.

dradovic commented 12 years ago

Just released in 2.0.0.