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
|
Hello, See the attached zip file. It contains two zip files, which represents the same solution, before and after the issue. To reproduce, open the first solution, and the model in the "ClassLibrary1" project. Right click in the "Value" property and select Refactor, Rename. Enter "StringValue" as the new name and unselect the option to keep the column name the same as the orginal name. Save and select to create a new Migration called Version2. Notice that the orginal column "Value" is dropped and a new column "StringValue" is created. The issue is that any data contained in "Value" will be lost. However, if modify the migration to do a RenameColumn instead, the column is renamed and data retained. Thanks Werner
|
|
|
|
|
Because of the way we generate migrations, we can never actually generate a column rename. (We don't keep a journal of actions; we calculate a set of differences. So we see only that there's no longer a Value column but there is now a StringValue column, with nothing to connect the two.) As you note, you can always correct the migration by replacing the drop-add pair of calls with a Rename instead. We agree it would be nice if we could identify renames, either by keeping a journal or by some combination of heuristics and prompting at migration creation time, but this isn't planned in at the moment. Thanks for the feedback -- it helps us prioritise! |
|
|
|
|
Hi Ivan, Its becoming clear that the designer as limitations when it comes to migartions. and its best to code migrations by hand. Would it be possible to add an additional menu to the "Migrations" menu to create an empty Migration without checking what changes were made to the designer? This will allow me to quickly create a migration whenever I refactor the schema, yet keep the same naming and versioning conventions as when I generated the full blown migrations. Thanks, Werner |
|
|
|
|
I don't really want to add a Migrations menu entry for this, because I think it could be confusing ("when should I choose one rather than the other?"). What I've done instead is to add a Clear All button to the Create Migration dialog, so that you can quickly exclude everything from the migration -- which will result in a blank migration just as you like, but within the existing conceptual model of deselecting the migrations you don't want us to generate. This will be in the next nightly build. One consequence of this design is that we will still save a checkpoint for subsequent migrations, so it will affect subsequent generated migrations, whereas a true 'create empty migration' command presumably would not. From your description of your intended workflow, that shouldn't be an issue for you. If it is an issue, we can revisit the design, or another approach would be to create a simple VS macro that creates the .cs file and adds the version attribute (we'd be happy to share the versioning convention if you go this route). Looking forward to your feedback! |
|
|
|
