What about starting NHibernate.Migrations? ;-) RP
On Saturday, July 12, 2014 1:53:12 AM UTC+1, Jeffrey Becker wrote: > > Ultimately I intend to drive my ddl off calculating the difference between > two mappings much like EF where as Schema update bases its ddl on database > metadata. I'm sure that both mechanisms could utilize a common set of > underlying classes to encapsulate their ddl generation. However, the > existing schema generation code has all of like 3 unit tests against it all > of them as a result of someone finding a bug. I'd be much more comfortable > building up a good suite of tests outside Nhibernate before even > considering trying that. > > On Friday, July 11, 2014 7:35:27 PM UTC-4, Darren Kopp wrote: >> >> Oh ok, that's good, I thought you were planning on using this >> functionality in the SchemaUpdate class >> <https://github.com/nhibernate/nhibernate-core/blob/master/src/NHibernate/Tool/hbm2ddl/SchemaUpdate.cs>. >> >> I actually think this functionality would be useful in that class as well, >> but opt-in, which is what I was referring to. >> >> On Friday, July 11, 2014 3:21:18 PM UTC-6, Jeffrey Becker wrote: >>> >>> Yes, I fully agree that any migration behavior needs to be completely >>> opt-in. To be clear I'm not proposing to rewrite any of the current Sql >>> generation code. I proposed to implement this as a library *separate >>> library outside NHibernate* proper which implements a workflow with the >>> two-step process and customizable migration. All I'm asking for here is >>> some decorator methods on Dialect which provide the necessary chunks of sql >>> and flags to make stuff sql-flavor independent. >>> >>> For example, when altering column definitions: >>> Sql Server uses "Alter [Table] Alter [Column]...", Oracle uses"Alter >>> [Table] Modify [Column]", Firebird and SQLite don't support altering >>> columns. One of the commits in the pull request adds 2 properties to >>> Dialect, *SupportsAlterColumn* and *AlterColumnString* >>> >>> I'm sure the DDL generation functionality could be rewritten to use the >>> underlying model that a script is a series of operations which is in turn a >>> series of statements, but why bother? It seems to work but there aren't >>> unit tests around it now so I wouldn't feel safe proposing changes. >>> >>> The pull request is here: >>> https://github.com/nhibernate/nhibernate-core/pull/282 >>> >>> On Friday, July 11, 2014 4:46:11 PM UTC-4, Darren Kopp wrote: >>>> >>>> You need to make this behavior opt-in, otherwise people will upgrade >>>> and possibly lose data because something may not be referenced in the >>>> model >>>> anymore (or perhaps multiple types mapped to same table returning >>>> different >>>> things). Entity framework is a two-step process and you can customize the >>>> migration, which mitigates this issue, but schema migration is not >>>> customizable and thus should not have this behavior enabled by default. >>>> >>>> On Friday, July 11, 2014 8:33:01 AM UTC-6, Jeffrey Becker wrote: >>>>> >>>>> Ok, pull request is submitted. >>>> >>>> -- --- 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.
