This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Currently i am testing the migration tool of the current beta ls3, and now i am running i a lot of questions: What i did first:
Now my first question: Why can't i created new Entities anymore in my model? I can add association but no entities via designer. If i delete "migrationProjectName="MigrationManager\MigrationManager.csproj" in the *.lsmodel file, it works. But then i have now migration support. My next questions: When my MainWindow is started, i want to check the Database and if needed i want to update. How can this be done? Has the MigrationManger a method to update automatically to the newest version? Since my App should do an autoupdate, i would really need such a cool migration tool like in rubyonrails. Is there a simple sample how can i update the database automatically, when starting the app? Thanks, Markus |
|
|
"Why can't i created new Entities anymore in my model?" This sounds like a bug. We have seen an issue that might be the same as this on a couple of systems, but not linked to migrations. Can you describe the symptoms? Do you get errors, or do you get a "no-drop" symbol? When you hover over the Entity icon in the toolbox, does it give you a "creates an entity" tooltip, or something like "version 2 by Microsoft Corporation"? And can you confirm that after you delete the migration project name from the .lsmodel file, it works again for you -- you can drag entities on? Thanks for any info you can provide! As a workaround, please try closing Visual Studio, opening a VS command prompt (Start menu > Visual Studio 2008 > Visual Studio Tools > Visual Studio 2008 Command Prompt) and running devenv /setup. This has fixed a similar problem in other environments though as I say I don't know if it's the same issue as you're seeing because we've never seen it linked to migrations before. To update to the latest version, use Process.Start to execute lsmigrate.exe without supplying a to_version argument. Alternatively, call Migrator.Migrate, passing a toVersion of null. Note that at present these both require the migration source code to be present in the working directory: they don't yet operate on a compiled assembly of migrations. We're going to see if we can improve this API before RTM, but it may have to be a post-3.0 thing due to time limitations (our focus for 3.0 is running the migrations through Visual Studio or from the command line). We don't yet have a sample for executing the migrations programmatically but I'll see if I can run something up for you. I'm assuming you'll want to distribute your migrations as a DLL rather than as source code, so we'll probably need to do those API improvements before this will be useful to you -- is that right? |
|
|
I got a "no-drop" symbol. But after i ran a migration, it i can create entities again. But running the first migration doesn't make sense, because i have already the youngest db version and i will get errors that tables already exists. I will try and report the devenv /setup workaround if i ran again into this problem. > We don't yet have a sample for executing the migrations programmatically but I'll see if I can run something up for you. I'm assuming you'll want to distribute your migrations as a DLL rather than as source code, so we'll probably need to do those API improvements before this will be useful to you -- is that right? Yes :) That would be more than nice. What i tried in my CheckDbVersion() method: var m = new MigrationManager.CreateAttachmentTable(); m.Up(); But didn't work. Ok, i see - where should it know what Database to update. This way would be very nice: Migrator.Migrate(ProviderType.SqlServer2005, Properties.Settings.Default.WpSoft4ClientConnectionString, null);
|
|
|
Migrating from Visual Studio is working, but from commandline i got these exceptions: E:\Development\MyProject\bin\Debug>lsmigrate mssql "Data Source=SYN-LAP-MAKE I copied the following files in the directory where i start lsmigrate from:
The database is in a subfolder .\Data Please please, tell me what i need to do in order to migrate from command line or better from code. When migrating from code i use now this line of code: Migrator.Migrate(ProviderType.SqlServer2005, Properties.Settings.Default.ConnectionString, null); But nothing happens here, no exception and no update. At the moment i am very hopeless and the documentation not really can help me. Here the example code of my migration file: namespace MigrationManager
|
|
|
Hi Caipus, Thanks for your feedback - we screwed up. We are not shipping an assembly in the beta that is required and therefore it won't run. We will be shipping an updated LightSpeed 3.0 beta install in 24 hours that will provide what is needed. We're sorry about this, even though this is beta software we don't want to be forgetting to include a file! It looks as though you are doing everything correctly at the moment - it was our fault. I will update this thread when the new beta build is posted. Thanks again for your feedback, John-Daniel Trask |
|
|
Hello John-Daniel, thank you for your efforts. Yes, i know - a beta should not be used for a productive application :) But i have to implement an autoupdate functionallity incl. Database update. Therfore the migration part would be exactly what i would need. Otherwise i am thinking about migratordotnet framework. Seems to be the same concept. But i would prefer your LS components. By the way: We often by components via www.componentsource.com - Your competitors are listened there but you not. Maybe its a tip for you ... Have a nice day Markus |
|
|
Hello Markus, The new build of the LS3 beta is now available for download. We believe this should also address the problem you saw with not being able to drag an Entity from the toolbox. I have also added an API to make it easier to use migrations programmatically from your application, instead of shelling out to lsmigrate.exe. I'm not sure it made it into the help file, so here are the details. There is a new static method Migrator.Migrate(IMigrationLoader, ProviderType, string, MigrationVersion?). This uses the migrations from the source specified in the IMigrationLoader. You can use the AssemblyMigrationLoader to use a compiled assembly as the source. So something like this: Assembly myMigrationsAssembly = /* load it however you like */; NOTE: If you are using a provider whose database engine is not registered in the GAC (e.g. MySQL), you must also have a reference to that database engine DLL (e.g. MySQL.Data.dll). The migration engine does NOT take care of locating the DLL for you. This should not be an issue for you since presumably you would be referencing the DLL anyway in this case. As always thanks for reporting this issue and please let us know if you run into any further difficulties. |
|
|
Thanks for the update and support. I followed your instructions, but nothing is updated. Assembly myMigrationsAssembly = Assembly.LoadFrom("MigrationManager.dll"); When using Migrator.Migrate(loader, ProviderType.SqlServer2005, WpSingleton.Instance.DbContext.ConnectionString, null); or for testings i tried: var m = new MigrationManager.CreateTestTabelle(); m.Version is 00010101000000 Migrator.Migrate(loader, ProviderType.SqlServer2005, WpSingleton.Instance.DbContext.ConnectionString, m.Version); nothing happens. No logging, no update, no exception ... If i call m.Up() directly, the console output is done, but then i have an exception - i think because "m" has no connection. Is there anything missing there?
Thats my migration class: namespace MigrationManager In the table DBVersion the version is "20091123162700" - so i think it should update, but the table isn't created.
Another question: How could i prevent the application to downgrade the database? |
|
|
It looks like we have a bug with handling null versions. I'm investigating this, but as an interim workaround, try passing: MigrationVersion.FromString("99991231235959") instead of null. We'll get this fixed for you asap -- thanks for letting us know about it. You can't currently prevent the application from downgrading the database. I'll look into this: probably rather than directly block a downgrade, what we might do is provide a "preview" method to query what migrations would be run, and your application could examine those and not run them if they were downward migrations. I'll post when this is available -- thanks for the suggestion! |
|
|
I have now committed a fix for the null handling issue. However it may take a little while for us to push the next beta up to the store -- we'll let you know. This also includes a solution for your downgrade requirement -- two solutions in fact! First, we have added the ability to "preview" a migration run, that is, to be told what would happen if you ran it, without the migrations actually executing. To use this, call the new Migrator.CreateMigrator method, passing in true for the previewOnly argument. Then subscribe to the MigrationExecuted event, and in your handler detect whether the previewed migration is downward. Finally, call Execute to run the preview: bool downward = false; Now you can examine the "downward" flag and decide whether to run the migration for real or not. Another technique in the upcoming drop which would also address your requirement is the ability to cancel a run in the MigrationExecuting event: Migrator m = Migrator.CreateMigrator(src, provider, connstr, version, false); Now if the migrations engine attempts to run a downward migration, the Executing handler will jump in and cancel the (rest of the) run. For your specific scenario, we'd recommend the preview approach as being more intention-revealing; cancellation support is really intended for other scenarios. We'll post again once these enhancements are in the store. |
|
|
It's migrating :) Super!!! Thank you very much If the next version is available, i will try the execute command. Is it possible to do "inserts/deletes/updates" of entities in the up or down method? |
|
|
The updated version is now available in the store. You can do anything you like in the Up or Down method, including inserts, deletes and updates. It's just code. Designer-generated migration projects do not automatically reference LightSpeed or your domain model, so if you want to use LightSpeed to do the inserts, updates and deletes, you'll need to add these references manually. Alternatively if you are doing bulk updates or deletes you can use ADO.NET directly. One issue is that I don't think the Up and Down methods have access to the data provider and connection string that the migration is being run against. I'm assuming your app would already know these e.g. from its configuration file, and could make them available, but if this does turn out to be an issue, let us know and we'll see what we can do! |
|
|
Yes, you are right. Do you have a trick to get the connection string in a migration class? Also referencing to the models seem to be a bit complex. My MainProject references already the Migration Project, so i think vice verca is not possible, because its a ring referencing. |
|
|
We don't currently expose the connection string to a migration, but it shouldn't be too hard to add this. The circular reference issue is a bit trickier. What I'd suggest as a workaround is to refactor your project structure slightly: * Pull out the LightSpeed model into a DLL project Another option is to include the migration code files directly in MainProject; however, assuming you're using the designer to generate migrations, you'd need to copy or link each migration as it was generated. Since you're already editing the migration code this might not be too much of a pain though. (Actually, you could probably hack the .lsmodel to make the designer generate migrations directly into the MainProject, though because the designer always generates into the project root, this could get pretty ugly, which is why we don't offer it in the UI.) You don't need the .lsmcheckpoint files because those are only used during generation, not when running the migrations. We'll see if we can come up with a cleaner solution for this but that definitely won't happen before 3.0. |
|