Hi Jeffrey, one thing I don’t quite understand is why do you want to write Migrations by hand while NHibernate already has all the Information you need for letting some sort of a framework do this automatically?
We already tell NHibernate what Tables and Columns are needed in terms of mappings. I mean why not just read the mappings, extract the Schema from them and then let some framework do the rest without having to say things like Create.Table(…) etc.? Let me rephrase my Question: What are the benefits of your migrations framework compared to – let’s say – FluentMigrator? Amro Von: [email protected] [mailto:[email protected]] Im Auftrag von Jeffrey Becker Gesendet: Freitag, 13. Februar 2015 14:21 An: [email protected] Betreff: Re: [nhibernate-development] Re: Migrations Status & Feedback request 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] <mailto:[email protected]> >: I'll fix this shortly. On Dec 10, 2014 7:45 AM, "Jan Schubert" < <mailto:[email protected]> [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 <mailto:[email protected]> [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 <mailto:[email protected]> [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] <mailto:[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.
