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 nhibernate-development+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
