The challenge with migrations is that it needs a full SQL query syntax for inspecting schema and modifying schema. This is an area where our syntax differs from SQL Server in notable ways (which we are incrementally improving) and we don't have absolute coverage. For example, some inspections and changes of schema require using our DDA interface. This means we'd have a fair bit of unique engineering to support this that wouldn't be reusable with other data providers we support.
Thanks Kendall. I will try that out. I really want to move from SQL CE 4 to VistaDB 5.
Would it be possible for developers to create a custom migration utility, utilizing DDA, that could be executed at run time? Essentially this would, at least for the short term, put the burden on the developer.
In my opinion that seems like a manageable workaround. In the product that my team is building we have to provide a way to migrate previous versions to the current. Having the database first approach limits us a bit.
We plan on digging into this again post-VistaDB 5.1. The big question for us is how useful EF 6 Code First is without Migrations - Migrations are a big block of unique functionality for us, whereas most of EF 6 Code First is just like standard EF from the provider standpoint.
We've had folks tell us they can get queries to work with the providers as they are (since there is the ability to interrogate schema already built into the EF provider) so if you stay away from migrations (which can be disabled in Code First) you may find that everything else is working for you. I know we've had some customers use it with success; our declarations saying that it isn't supported is really a function of us not having a test suite specifically for Code First which limits our ability to respond to support tickets on it.
If you don't mind me asking, is there a limitation with providing Code First with Migrations? I agree that Code First may not be as worthwhile without them.
Is there any time table for this feature?
1 person likes this idea