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.
