I'd expect the update statement to be included in the migration from v1 to v2 as a builder.Sql statement. The binaries you ship should compile in all the migration classes. The migrator will then find all the migrations it needs to run to get from the current version to the target version. So in your case of a customer deploying v3, the migrator would find the migrations for both v2 and v3 and execute them in order.
On Monday, February 16, 2015 at 3:56:33 AM UTC-5, Jan Schubert wrote: > > Well done! Do you have any ideas to migrate data? In my project it is > necessary to execute an UPDATE statement, after create new columns. If I > release a new software to my customers and one of the customers overleaps a > version, I can't use the current mapping. > > E.g. > > Version 1: > Table: User -> Columns: Name, Age > Version 2: > Table: User -> Columns: Name, Age, Gender > Version 3: > Table: User -> Columns: Name, Age > > In version 1 the User table has no Gender column. For the migration to > version 2 I want to execute an UPDATE statement like this: > UPDATE User SET Gender = 'm' WHERE Name LIKE 'John' > In version 3 I will drop the column. If a customer overleaps version 2 and > install version 3 after version 1, I can't create the UPDATE statement > because my POCO and the mapping file has no Gender property. > > On Friday, February 13, 2015 at 2:21:03 PM UTC+1, Jeffrey Becker wrote: >> >> So I finally got around to breaking the stuff I need in nhibernate-core >> and the migrations framework stuff out into separate repos. Core work can >> be seen at: >> >> >> https://github.com/jeffreyabecker/nhibernate-core/tree/operations-framework >> >> Basically this work breaks schema generation up into a series of >> DdlOperation classes and corresponding DTOs which encapsulate the logic for >> building DDL. From that point I can build all the migrations stuff out in >> a separate library. I prefer to keep the schema generation in the core >> framework for several reasons. First, my coworkers who've gone from older >> EF schema generations to migrations have reported changes in the DDL >> generated. Second, this allows me to leverage the existing test suites >> around schema generation to ensure I've kept things consistent. Third, some >> of the logic that this needs is appropriately private to Cfg.Configuration. >> >> On Friday, February 6, 2015 at 5:25:31 AM UTC-5, Jan Schubert wrote: >>> >>> Another idea: Should I use the configuration "QuerySubstitutions" to >>> replace the values? >>> Sample: >>> from -> ADD COLUMN CON0001 BIT DEFAULT false NOT NULL >>> to -> ADD COLUMN CON0001 BIT DEFAULT 0 NOT NULL >>> >>> Am Donnerstag, 5. Februar 2015 16:58:34 UTC+1 schrieb Jan Schubert: >>>> >>>> I try to set default values for my columns. My problem is that the >>>> default value is only a string. I use the migration framework for >>>> different >>>> databases. >>>> Each database has an own dialect for a default value. E.g. Oracle use >>>> "EMPTY_BLOB()" for an empty binary column and MSSQL use "0x". >>>> >>>> I think it is necessary to extend the SqlType class with a method like >>>> "GetDefaultValue(byte[] value) : DefaultValue" and the Dialect class >>>> should >>>> convert the DefaultValue to an SQL string. >>>> >>>> Would my idea fit into the concept? >>>> >>>> >>>> Am Freitag, 19. Dezember 2014 19:00:11 UTC+1 schrieb Jeffrey Becker: >>>>> >>>>> So here's my conundrum. I'd really like to break the majority of the >>>>> code out into a separate library; there's a lot of ancillary stuff in >>>>> there. Because of how baked-in and dialect dependent ddl generation is, I >>>>> don't think its possible to implement this as purely a layer-on-top. >>>>> >>>>> As I see it there are distinct several components in my work so far: >>>>> >>>>> - The core ddl generation framework -- an OO framework for >>>>> representing ddl operations >>>>> - The mapping diff engine -- Take two Configurations, look at >>>>> their mappings and generate a set of operations which goes from A to B >>>>> - The migration framework & executor >>>>> - The fluent builder interface >>>>> >>>>> I feel like the first two are things which need to be in the core >>>>> nhibernate where as the last two are stuff which is obviously better to >>>>> separate out. >>>>> On Wednesday, December 10, 2014 8:04:02 AM UTC-5, Gunnar Liljas wrote: >>>>>> >>>>>> I agree with Ricardo. I really like the idea, but it should be in a >>>>>> separate project. >>>>>> >>>>>> /G >>>>>> >>>>>> 2014-12-10 13:47 GMT+01:00 Jeffrey Becker <[email protected]>: >>>>>> >>>>>>> I'll fix this shortly. >>>>>>> On Dec 10, 2014 7:45 AM, "Jan Schubert" <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> The fix works great! But the column names are still quoted. I >>>>>>>> changed this and pushed it as a pull request. >>>>>>>> >>>>>>>> Am Dienstag, 9. Dezember 2014 16:59:41 UTC+1 schrieb Jeffrey Becker: >>>>>>>>> >>>>>>>>> Fixes are in and your pull request is merged in the migrations >>>>>>>>> branch. >>>>>>>>> >>>>>>>>> On Monday, December 8, 2014 3:44:15 AM UTC-5, Jan Schubert wrote: >>>>>>>>>> >>>>>>>>>> What exactly would you change in line 404? >>>>>>>>>> >>>>>>>>>> Am Donnerstag, 4. Dezember 2014 20:30:22 UTC+1 schrieb Jeffrey >>>>>>>>>> Becker: >>>>>>>>>>> >>>>>>>>>>> The behavior described seems to be centered in >>>>>>>>>>> Table.GetThreePartName; Table.cs Line 404. Stripping out the >>>>>>>>>>> behavior is >>>>>>>>>>> causing a lot of unit-test failures which I don't have time to >>>>>>>>>>> address >>>>>>>>>>> today. >>>>>>>>>>> >>>>>>>>>>> On Thursday, December 4, 2014 2:05:22 PM UTC-5, Jeffrey Becker >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I've found it. I'm just stripping it out. >>>>>>>>>>>> >>>>>>>>>>>> On Wednesday, December 3, 2014 11:05:14 AM UTC-5, Jan Schubert >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I have a problem with the SchemaExport class. Without your >>>>>>>>>>>>> changes for the migration framework, the tables wasn't quoted >>>>>>>>>>>>> automaticly. >>>>>>>>>>>>> So, if I use PostgreSQL as database, the table names are upper >>>>>>>>>>>>> case. >>>>>>>>>>>>> PostgreSQL enables uppercase names automaticly, if a name is >>>>>>>>>>>>> quoted. I need >>>>>>>>>>>>> lower case table names for PostgreSQL and CamelCase names for >>>>>>>>>>>>> MSSQL table >>>>>>>>>>>>> names. I have the same problem in my "IMigration" class. >>>>>>>>>>>>> >>>>>>>>>>>>> Is it possible to use the auto-quote setting of NHibernate? >>>>>>>>>>>>> >>>>>>>>>>>>> I try to fix the problem, but I can't do this with my >>>>>>>>>>>>> insufficient knowledge. >>>>>>>>>>>>> >>>>>>>>>>>>> PS: The last commit of your branch "migrations" is not >>>>>>>>>>>>> compilable. Some files are missing. >>>>>>>>>>>>> >>>>>>>>>>>>> Am Freitag, 14. November 2014 16:38:44 UTC+1 schrieb Jeffrey >>>>>>>>>>>>> Becker: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'd like some feedback on how people feel about the current >>>>>>>>>>>>>> state of the migrations feature. I've used the existing code in >>>>>>>>>>>>>> a project >>>>>>>>>>>>>> and it seems to work pretty well. That said, I haven't finished >>>>>>>>>>>>>> all the >>>>>>>>>>>>>> features that I originally wanted. The key points I've hit so >>>>>>>>>>>>>> far are: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Unified DDL generation framework (no weirdness like EF >>>>>>>>>>>>>> where different exports generate different sql) >>>>>>>>>>>>>> - Migration Factory & Version Store >>>>>>>>>>>>>> - Usable Configuration >>>>>>>>>>>>>> - Fluent Builder >>>>>>>>>>>>>> >>>>>>>>>>>>>> That said, generating migrations auto-magically is turning >>>>>>>>>>>>>> out to be much more work than I'd originally anticipated. I >>>>>>>>>>>>>> think the >>>>>>>>>>>>>> feature is definitely achievable, I just don't have the time to >>>>>>>>>>>>>> do it right >>>>>>>>>>>>>> now. I'm proud of what the migrations code-base looks like >>>>>>>>>>>>>> right now. I >>>>>>>>>>>>>> think its the right approach. I'm also concerned about having >>>>>>>>>>>>>> this sit >>>>>>>>>>>>>> unmerged for too long. The longer I'm a fork the more work I >>>>>>>>>>>>>> have to keep >>>>>>>>>>>>>> track of the upstream. Pending some positive feedback and >>>>>>>>>>>>>> cleanup work I >>>>>>>>>>>>>> think I'd like to try to get this merged. Are people >>>>>>>>>>>>>> comfortable with this? >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>> >>>>>>>> --- >>>>>>>> You received this message because you are subscribed to a topic in >>>>>>>> the Google Groups "nhibernate-development" group. >>>>>>>> To unsubscribe from this topic, visit >>>>>>>> https://groups.google.com/d/topic/nhibernate-development/aIGssJRjHcw/unsubscribe >>>>>>>> . >>>>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>>>> [email protected]. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> -- >>>>>>> >>>>>>> --- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "nhibernate-development" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected] >>>>>>> . >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- --- You received this message because you are subscribed to the Google Groups "nhibernate-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
