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 <jeffrey....@gmail.com>: >>>> >>>>> I'll fix this shortly. >>>>> On Dec 10, 2014 7:45 AM, "Jan Schubert" <xp.dev....@gmail.com> 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 >>>>>> nhibernate-development+unsubscr...@googlegroups.com. >>>>>> 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 nhibernate-development+unsubscr...@googlegroups.com. >>>>> 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 nhibernate-development+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
