>From a practical perspective the DdlOperation code is needed just to properly expose the internal data structures of NHibernate in a consumable way. From there its largely irrelevant what migration engine is consuming them and generating coded migrations. The key point is that reading the hbm.xml files is extremely problematic for a number of reasons. First, mapping by code and auto mapping eliminate the hbm.xml files. Second, even if that were the case the Configuration needs to parse the whole set to make things coherent. Finally much of the information needed to generate the migrations against the engine is private to Configuration and rightly so. This is doubly true for comparing two Configurations and determining the deltas for the migration framework.
On Friday, February 13, 2015 at 1:15:53 PM UTC-5, Amro El-Fakharany wrote: > > FluentMigrator is also db independent and I'm actually using it since some > time to generate the schema for NHibernate. > What would truly be awesome is a framework which would inspect the > mappings of nhibernate and automatically executes the appropriate > operations against FluentMigrator (or any other migration "engine") to > generate the schema. > This shouldn't require any changes to nhibernate and if you're going down > that path you already have at least one volunteer :) > > I don't know how others see this but my own opinion is that schema > generation shouldn't be a responsibility of nhibernate at all. > And I'm saying this although I really like your concept of DdlOperation > and the related code is much cleaner than what was there before! > > Amro > Am 13.02.2015 18:00 schrieb "Jeffrey Becker" <[email protected] > <javascript:>>: > >> To answer your question succinctly, >> >> The benefit is that it allows people to write database independent >> migrations using the principles that NHibernate uses to ensure db >> independence. The whole framework is dialect-aware and therefore pretty >> darn database independent. The data type and id generator specifications >> can be used exactly the same way as in the mappings. >> >> The structure you proposed in terms of using the mappings is actually >> exactly what I'm shooting for. My system uses mappings as NHibernate >> parses them in the Config class. The work in repo specified above is all >> about splitting those mapping classes up to encapsulate the DDL generation >> framework in a reusable way. From there my framework can pick up the >> mappings and generate that migration class. The framework can also store >> some history about the mappings so it can generate differential updates and >> properly update data. There's also facilities to auto-update the database >> based on these classes. >> >> On Friday, February 13, 2015 at 9:57:20 AM UTC-5, Amro El-Fakharany wrote: >>> >>> 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:nhibernate- >>> [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]>: >>> >>> I'll fix this shortly. >>> >>> On Dec 10, 2014 7:45 AM, "Jan Schubert" <[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 >>> [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. >>> >>> >>> >>> -- >>> >>> --- >>> 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. >>> >> -- >> >> --- >> 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] >> <javascript:>. >> 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.
