I'm going through my changes for the whole migration thing and I've notice that my DDL output differs slightly from the existing output in several ways:
1. Identifier quoting & qualification produced by GetIf[Not]ExistsXXX methods is more consistent in my version. I've checked the docs for sql server, which is the only dialect that implements those methods, and both quoting schemes are valid and correct. 2. In the existing method, Foreign Keys generated in the Create Table statement ignored cascade options, mine does not. SQLite, which is the only dialect that doesnt support Foreign Keys in alter table has always parsed the cascade clause even before it actually enforced the constraint. 3. in the existing code, if a column is unique in the hbm the create table statement will have an un-named unique constraint even if the Dialect SupportsUniqueConstraintInCreateAlterTable. Mine will prefer to put the unique in an alter table statement and always include the constraint name if its there and supported. 4. In the existing code, if the first column in the table is the only column of the primary key, an extra space is tacked on to the padding. Do changes like this constitute a breaking change? The test suite passes which gives me a lot of confidence that my changes aren't going to break the automated tools. -- --- 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.
