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
|
Hi, Are the migrations tools designed to work with hand coded entities at all? I can't find a way to activate the tools other than by adding a blank designer model so that the menu shows up. Thanks |
|
|
If you are referring to the tooling in the designer, then no, its intended to work with a model being managed through the designer. If you are using hand coded entities you will need to manually craft your migrations as well.
|
|
|
I'm fine with hand writing them, but how is it working out the current version the database is on etc? You don't appear to use a Version table like Entity Framework etc does. I see the auto generated ones have some magic XML that go along with them, do I need to do something similar? |
|
|
We do use a versioning table (DBVersion), its not created until its needed though which is generally the first time you run a migration. It will hold the current version which has been migrated to, initially that's nothing so your first migration should represent the initial schema. To code these by hand you will need to follow the convention we use for version numbering which is to use a DateTime prefix on the filename for each migration to indicate what version it represents in the form (yyMMddhhmmss) e.g.
Each file should contain a single class derived from Migration and override the Up and Down methods with your implementation for migrating up and down. You can then call the available methods on the base class (e.g. AddTable, DropTable, ExecuteNativeCommand) to perform the actual migration work.
|
|
|
Ah, that makes sense. I'll take it for a spin now. Thanks =) |
|