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
-~----------~----~----~----~------~----~------~--~---

Reply via email to