Everything is currently in the model branch and will be merged into trunk for the 1.0 release. There are some significant breaking changes, so it might not be completely smooth sailing :) For the release I'll prepare some release notes and upgrade information, but for the time being you'll just have to wing it if you decide to use it.
On Thu, Jul 30, 2009 at 10:29 AM, Dmitiry Nagirnyak <[email protected]>wrote: > Yeah. I see what you are talking about. There are some issues obviously. > But I still belive the order should be as wrote before. > > Too tough alteration might throw or maybe just do exactly what developer > says. > The dev should know what he/she si doing. > > Will I be able to grab the version with alteretinos altering from trunk :) > ? > > Cheers. > > 2009/7/30 James Gregory <[email protected]> > > I agree about 1 and 2, but alterations are a tricky beast. The example I >> always use is this: What happens if you define a HasManyToManyConvention, >> then in an alteration change a HasMany collection to a HasManyToMany; how >> does the new many-to-many get the convention applied to it? It won't unless >> the conventions are last. >> Alterations have the ability to alter the existing shape of a mapping, not >> just change the settings on it. That new shape will not have any existing >> conventions applied to it unless conventions are the last thing to be >> applied. >> >> We've had this discussion between the developers and it's a solved issue >> for 1.0. >> >> On Thu, Jul 30, 2009 at 1:17 AM, Dmitiry Nagirnyak <[email protected]>wrote: >> >>> Hi James, >>> >>> Thanks a lot for that. I'll modify my conventions for now. >>> In my opinion the order should be this: >>> >>> 1. Conventions. >>> 2. Mapping (override conventions), >>> 3. Alterations (override both 1 and 2). >>> >>> I think so because of Conventions define general structure that should be >>> common. It can be defined in a separate assembly to be reused by the whole >>> company among many projects. >>> >>> Mapping defines particular mapping for a particular class that Convention >>> cannot handle. Can also be generic and in a separate assembly to be able to >>> reuse. >>> >>> The alterations are the things related to concrete implementations for >>> concrete project, thus specific to a concrete project and generally should >>> not be reused among different projects. >>> >>> That was my understanding at least :) >>> >>> Cheers, >>> Dmitriy. >>> >>> 2009/7/29 James Gregory <[email protected]> >>> >>> Alterations don't override conventions. >>>> Mapping >>>> | >>>> Alterations >>>> | >>>> Conventions >>>> >>>> Thankfully this will be changing for 1.0, because I'm sick of explaining >>>> it :) >>>> >>>> For the time being change your convention so it checks if there's a >>>> value before making any changes, that way your alteration change won't get >>>> overwritten. >>>> >>>> On Wed, Jul 29, 2009 at 8:14 AM, Dmitiry Nagirnyak <[email protected]>wrote: >>>> >>>>> Anybody? >>>>> >>>>> 2009/7/27 Dmitiry Nagirnyak <[email protected]> >>>>> >>>>> I found where the problem is. >>>>>> I use alterations. But the alteration that defines cascade="all" does >>>>>> NOT override the convention (which sets cascade="save-update"). >>>>>> >>>>>> So now the question is HOW should I override the convention with my >>>>>> alteration? >>>>>> >>>>>> Cheers, >>>>>> Dmitriy. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
