Yes, it does. All tests have passed, so if it has broken something then we
definitely need to get it covered by tests.

On Mon, Jan 5, 2009 at 8:53 AM, Andrew Stewart <andrew.stew...@i-nnovate.net
> wrote:

> Hi James
> Does this break any backwards compatibility? Don't mind if it does just so
> that I can check if the auto-mapping still works.
>
> Andy
>
>
> On Mon, Jan 5, 2009 at 12:14 AM, James Gregory <jagregory....@gmail.com>wrote:
>
>> FYI I've also made a post about this too: Fluent NHibernate SubClass
>> syntax 
>> changes<http://blog.jagregory.com/2009/01/05/fluent-nhibernate-subclass-syntax-changes/>
>>
>>
>>
>> On Mon, Jan 5, 2009 at 12:06 AM, James Gregory 
>> <jagregory....@gmail.com>wrote:
>>
>>> Just a heads up, I've merged my changes into trunk.
>>> The changes are (briefly):
>>>
>>>    - DiscriminateSubClassesOnColumn now defaults to string if no
>>>    discriminator type is specified
>>>    - SubClass now defaults to using the class name as a discriminator
>>>    value if non is specified
>>>    - IdentifiedBy and MapSubClassColumns are now merged into several
>>>    overloads for SubClass
>>>    - SubClass is now repeatable fluently
>>>    - DiscriminateSubClassesOnColumn can now NOT be used within a
>>>    subclass (but SubClass itself now can be), because this is not valid
>>>
>>> As I discovered, what I said before wasn't strictly true. You can't have
>>> sub discriminators on a different column, NHibernate doesn't like that.
>>>
>>> On Sun, Dec 21, 2008 at 8:54 PM, James Gregory 
>>> <jagregory....@gmail.com>wrote:
>>>
>>>> I've just committed the above syntax changes into a branch (
>>>> http://fluent-nhibernate.googlecode.com/svn/branches/jg-subclass),
>>>> SubClassPart has now got some nasty generics going on, but it seems to 
>>>> work.
>>>> I say seems, because our test coverage of the subclass stuff is pretty low.
>>>> I'd definitely like to get this upped before I committed any changes of
>>>> these sort to trunk.
>>>> I'm also open to alternative syntaxes if anyone has any suggestions.
>>>>
>>>>
>>>> On Sun, Dec 21, 2008 at 8:31 PM, James Gregory <jagregory....@gmail.com
>>>> > wrote:
>>>>
>>>>> Hey everyone,
>>>>> I've been thinking about the syntax for subclasses, I think we could
>>>>> refine it a bit. I've got some suggestions I'd like your thoughts on.
>>>>>
>>>>> Currently to map two subclasses (A as the parent, B and C as
>>>>> subclasses) you use this mapping:
>>>>>
>>>>> public AMap()
>>>>> {
>>>>>   DiscriminateSubClassesOnColumn<string>("Type")
>>>>>     .SubClass<B>()
>>>>>       .Identifier("bID")
>>>>>       .MapSubClassColumns(m =>
>>>>>       {
>>>>>         m.Map(x => x.BProperty);
>>>>>       })
>>>>>     .SubClass<C>()
>>>>>       .Identifier("cID")
>>>>>       .MapSubClassColumns(m =>
>>>>>       {
>>>>>         m.Map(x => x.CProperty);
>>>>>       });
>>>>> }
>>>>>
>>>>> and to map a structure where C derives from B instead of A:
>>>>>
>>>>> public AMap()
>>>>> {
>>>>>   DiscriminateSubClassesOnColumn<string>("Type")
>>>>>     .SubClass<B>()
>>>>>       .Identifier("bID")
>>>>>       .MapSubClassColumns(m =>
>>>>>       {
>>>>>         m.Map(x => x.BProperty);
>>>>>         m.DiscriminateSubClassesOnColumn<string>("Type")
>>>>>           .SubClass<C>()
>>>>>             .Identifier("cID")
>>>>>             .MapSubClassColumns(m =>
>>>>>             {
>>>>>               m.Map(x => x.CProperty);
>>>>>             });
>>>>>       });
>>>>> }
>>>>>
>>>>> Firstly, the identifier isn't implied in fluent nhib, so you always
>>>>> have to specify this. It was my understanding that NH allows you to not
>>>>> specify a discriminator value and use the class name instead; we should 
>>>>> use
>>>>> this as the default in my opinion. So disregarding Identifier, we're left
>>>>> with MapSubClassColumns; in most cases you're going to have something to 
>>>>> map
>>>>> in your subclass, so I think this should probably be inlined to the 
>>>>> subclass
>>>>> call.
>>>>>
>>>>> I propose the following syntax (for the first example):
>>>>>
>>>>> public AMap()
>>>>> {
>>>>>   DiscriminateSubClassesOnColumn<string>("Type")
>>>>>     .SubClass<B>(m =>
>>>>>     {
>>>>>       m.Map(x => x.BProperty);
>>>>>     })
>>>>>     .SubClass<C>(m =>
>>>>>     {
>>>>>       m.Map(x => x.CProperty);
>>>>>     });
>>>>> }
>>>>>
>>>>> SubClass could also have overloads to explicitly set the identifier,
>>>>> and possibly also to not specify any mappings at all.
>>>>>
>>>>> There's also the case of nested subclasses, which is admittedly a case
>>>>> I hadn't really considered; with that in mind, the syntax is less than
>>>>> ideal! This is mainly because in a subclass if NH finds another subclass 
>>>>> it
>>>>> assumes that it's a part of the same discriminator column tree; without us
>>>>> having a specific case for this, our users have taken to reusing the
>>>>> DiscriminateXXX method with the same column name. This usage has actually
>>>>> led to a hack in the code too, because the subclass was getting another
>>>>> discriminator element (when it should only get one if it's discriminating 
>>>>> on
>>>>> a different column to it's parent).
>>>>>
>>>>> We've basically got two different situations to support here, one where
>>>>> we're specifying a subclass of a subclass that's using the same
>>>>> discriminator column (the NH inferred default), and then a new subclass 
>>>>> tree
>>>>> within a subclass that uses a different column. The latter can keep the
>>>>> existing syntax, but the former should really be simplified.
>>>>>
>>>>> I propose the following syntax for both of these:
>>>>>
>>>>> // subclass of a subclass
>>>>> public AMap()
>>>>> {
>>>>>   DiscriminateSubClassesOnColumn<string>("Type")
>>>>>     .SubClass<B>(m =>
>>>>>     {
>>>>>       m.Map(x => x.BProperty);
>>>>>       m.SubClass<C>(sm =>
>>>>>       {
>>>>>         sm.Map(x => x.CProperty);
>>>>>       });
>>>>>     });
>>>>> }
>>>>>
>>>>> // subclass of a subclass, different column
>>>>> public AMap()
>>>>> {
>>>>>   DiscriminateSubClassesOnColumn<string>("Type")
>>>>>     .SubClass<B>(m =>
>>>>>     {
>>>>>       m.Map(x => x.BProperty);
>>>>>       m.DiscriminateSubClassesOnColumn<string>("AnotherType")
>>>>>         .SubClass<C>(m =>
>>>>>         {
>>>>>           m.Map(x => x.CProperty);
>>>>>         });
>>>>>     });
>>>>> }
>>>>>
>>>>> What does everyone think? Please correct me if my NH logic is wrong,
>>>>> I've not dealt a great deal with nested subclasses.
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
> --
> =================
> I-nnovate Software - Bespoke Software Development, uk wirral.
> http://www.i-nnovate.net
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Fluent NHibernate" group.
To post to this group, send email to fluent-nhibernate@googlegroups.com
To unsubscribe from this group, send email to 
fluent-nhibernate+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/fluent-nhibernate?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to