Anne, I definitely would like to help make sure that I'm the last person to stumble across this peculiar issue. To this end, I created a JIRA issue and submitted an associated pull request @ https://github.com/nhibernate/nhibernate-core/pull/166. Will be overjoyed if it gets merged in one day :-)
While doing this I also noticed that the folder that contains some of the mapping-by-code tests is named incorrectly; so I jumped ahead and created a JIRA issue & a pull request for that too: https://github.com/nhibernate/nhibernate-core/pull/167. Not sure if such small things are meant to be pulled that way, but there it is just in case it makes someone's life easier. Best regards, Dawid On Monday, November 5, 2012 4:05:45 PM UTC+1, [email protected] wrote: > > Dawid, > That's great that you were able to figure it out, and thank you for > getting back to the group with your find! If you have the time, you should > consider submitting your fix back as a pull request -it would would mean > you don't have to maintain your fix yourself, and would mean that you can > be the last person to hit this particular problem. > > > > On Mon, Nov 5, 2012 at 6:23 AM, Dawid Ciecierski > <[email protected]<javascript:> > > wrote: > >> Hello, >> >> Thank you for sharing this. Your point of view that, broadly speaking, >> bugs in less-used parts of the codebase are not at all impossible, I >> started poking around and came across what should be the reason. Will >> briefly describe it here in case anyone stumbles across this in the future. >> >> When mapping by code comes across a property mapping, it needs to get to >> the MemberInfo of the property being mapped. In the case of lambda >> expressions, in most cases, a simple cast and peek inside of the lambda >> should suffice, and hence the following is done in >> TypeExtensions.DecodeMemberAccessExpression: ((MemberExpression) >> expression.Body).Member. All is fine until we get inheritance in the >> mix; in such cases the *DeclaringType *property of MemberInfo is still >> Superclass, but the *ReflectedType *also becomes Superclass instead of >> Subclass. When NHibernate checks for properties being part of a >> composite key later on, in ModelMapper.MapRootClass (line 758 in >> v3.3.1), it is unable to match class properties together. >> >> All I did was change ComposedIdCustomizer to use >> DecodeMemberAccessExpressionOf instead of DecodeMemberAccessExpression. >> All tests still pass, and my classes are mapped properly. >> >> Thank you again for your help! >> Dawid Ciecierski >> >> >> On Wednesday, October 31, 2012 3:53:45 PM UTC+1, [email protected] wrote: >> >>> Dawid, >>> It sounds like a bug to me too, which actually would not be terribly >>> surprising. In general, I've found that features that stray from the >>> recommended way you would want to map things if you were writing a >>> greenfield app tend to be a bit less solid than things that you only hit in >>> strange legacy situations. In particular, if it's a really ugly compromise, >>> people tend to refactor their database away from those structures, so those >>> parts of the NH codebase haven't been hit as hard as the more typical >>> structures, wich have been hit exhaustively and are extremely reliable at >>> this point. (not a knock on NH really, this is how all software ends up) >>> The NH community tents to be anti-composite id for a number of excellent >>> reasons, so it would be an example of a less-hit area of the NH codebase, >>> though I've used it successfully a number of times-just not this particular >>> inheritance situation. Speaking of composite ids, I feel obligated to >>> suggest that you consider moving away from this structure if possible, it >>> will be an ongoing source of extra complexity for you. >>> >>> I personally tend to use use fluent rather than Conform so I can't speak >>> to the details of implementation there-but I know with fluent, it's >>> possible to run the older xml mapping files for some classes alongside the >>> new code mappings for other classes. If this structure works at all, it'll >>> work that way - so if that's even an option for you, I'd give xml mappings >>> a try here. If nothing else, you'll see if it's a conform issue or a core >>> NH issue, so it'll give you some data to put in a jira, and where to file >>> it. Best case, it works and you can do that for the time being! >>> >>> >>> >>> On Wed, Oct 31, 2012 at 8:12 AM, Dawid Ciecierski <[email protected] >>> > wrote: >>> >>>> Hello again, >>>> >>>> We're closer to product completion, and are coming across this issue >>>> again. Would love to know if the above is by design, and how we may be >>>> able >>>> to overcome the problem with ComposedId made up of superclass properties. >>>> >>>> Will be grateful for any advice at all. >>>> >>>> Regards, >>>> Dawid Ciecierski >>>> >>>> >>>> On Wednesday, August 29, 2012 11:22:54 AM UTC+2, Dawid Ciecierski wrote: >>>>> >>>>> Hello, >>>>> >>>>> This question was posted on StackOverflow <http://goog_632167627>, >>>>> but expanding on it here. I'm having trouble understanding NHibernate >>>>> behaviour when mapping subclasses, and would like to ask you for help as >>>>> I >>>>> cannot determine if what I'm seeing is misconfiguration on my part or a >>>>> bug >>>>> - with my limited knowledge of mapping by code and NHibernate >>>>> >>>>> We're loosely following DDD principles, and have a simple base class >>>>> for all of our aggregate roots (main business objects). This base class >>>>> has >>>>> no meaning of itself, and therefore is declared abstract and is not >>>>> mapped. >>>>> Only the inheriting specific classes are mapped, also mapping properties >>>>> inherited from the base abstract class. >>>>> >>>>> A problem arises when we try to combine an inherited property with a >>>>> property declared on the concrete class into a composed id like so: >>>>> >>>>> public class BaseClass >>>>> { >>>>> public int InheritedId { get; set; } >>>>> } >>>>> >>>>> public class Subclass : BaseClass >>>>> { >>>>> public int OwnId { get; set; } >>>>> } >>>>> >>>>> public class SubclassMap : ClassMapping<Subclass> >>>>> { >>>>> public SubclassMap() >>>>> { >>>>> Table("Subclass"); >>>>> ComposedId(x => { >>>>> x.Property(p => p.InheritedId); >>>>> x.Property(p => p.OwnId); >>>>> }); >>>>> } >>>>> } >>>>> >>>>> Given the above mapping, explicit model mapper only maps OwnId to be >>>>> the primary key of the table, skipping on the InheritedId. As I said >>>>> before, it may be a bug (as suggested on StackOverflow) or perhaps >>>>> NHibernate needs some clear instructions that I'm trying to use implicit >>>>> polymorphism? If it is the latter, how do I do that with Loquacious? >>>>> >>>>> Kind regards, >>>>> Dawid Ciecierski >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "nhusers" group. >>>> To view this discussion on the web visit https://groups.google.com/d/** >>>> msg/nhusers/-/gDfSpSOUq2kJ<https://groups.google.com/d/msg/nhusers/-/gDfSpSOUq2kJ> >>>> . >>>> >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to nhusers+u...@** >>>> googlegroups.com. >>>> >>>> For more options, visit this group at http://groups.google.com/** >>>> group/nhusers?hl=en <http://groups.google.com/group/nhusers?hl=en>. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "nhusers" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/nhusers/-/AUQICrgeHWMJ. >> >> To post to this group, send email to [email protected]<javascript:> >> . >> To unsubscribe from this group, send email to >> [email protected] <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/nhusers?hl=en. >> > > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To view this discussion on the web visit https://groups.google.com/d/msg/nhusers/-/7o6OQQYKd18J. 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/nhusers?hl=en.
