Chris, I agree, I would not expect that situation to be automappable. The
reason why I cited it though was to illuminate how making your change would
break it for people using the normal fluent interface.
Can you explain why using ReflectedType or DeclaringType (I haven't thought
carefully about which one should be used) is a "hack"? I was not suggesting
that it be used in the code base, rather than the user would specify it if
they were using the automapping.
Perhaps I am still missing the point?
On Fri, Dec 12, 2008 at 1:49 PM, Chris Marisic <chrismari...@hotmail.com>wrote:
>
> Using prop.ReflectedType.Name really seems like much more of a hack
> than an actual solution (I even said this when I added code to my
> personal copy of FH) in the IdentityPart class. I think this really
> stems from the fact GetPrimaryKey really has 2 very different meanings
> between it existing in AutoMap and regular mapping. Perhaps the
> solution is to create a base class that contains public virtual
> Func<object, string> GetPrimaryKeyName where the regular mapping class
> does public override Func<PropertyInfo, string> and the auto mapping
> class does public override Func<Type, string>. I'm not exactly sure
> how inheritance works between overriding Func<x,y> methods.
>
> Does a base class with regular mapping and auto mapping deriving from
> it in this regard make sense? There really is 2 very different
> meanings in the terms of auto map / regular map, in terms of auto
> mapping if you have the example
>
> public class Customer
> {
> public int PersonID { get; set; }
> }
>
> Will it even be able to figure out that PersonID is the PK? I don't
> think it will and will just attempt to select ID, PersonID from
> Customer and will error, am I right?
>
> With auto mapping I don't think it really should be able to figure out
> that PersonID is the PK for Customer in this situtation unless you
> goto my other post where you can specifiy conventions to target exact
> conditions whether it be a class or a predicate like the .Where()
> clause implements now with my suggested
> WithConventionWhere(convention => convention.GetPrimaryKeyName = type
> => "PersonID, t => t == typeof (Customer))
>
> I really think this goes to my original point I really believe there
> needs to be some type of WithConventionWhere or similar method for
> auto mapping that will allow people to handle these really weird cases
> that you gave a perfect example of because to my knowledge there's no
> way to setup automapping to handle this case unless you only need to
> map that singular class and never need to map any other class.
>
> On Dec 11, 8:25 pm, "Paul Batum" <paul.ba...@gmail.com> wrote:
> > I've not followed the discussion completely, so sorry if I'm off the mark
> > here.
> >
> > Currently, GetPrimaryKeyName is:
> >
> > public Func<PropertyInfo, string> GetPrimaryKeyName = prop => prop.Name;
> >
> > Chris suggested that it should be:
> >
> > public Func<Type, string> GetPrimaryKeyName = type => "Id";
> >
> > I'm uncomfortable with this change, because I think if somebody defines
> this
> > class:
> >
> > public class Customer
> > {
> > public int PersonID { get; set; }
> >
> > }
> >
> > And then attempts to map it, they will get CustomerID instead of
> PersonID,
> > which is not intuitive. You need to remember here that there are people
> > using nhibernate against legacy databases which may not follow expected
> > conventions. I think it is unreasonable to expect this person to fiddle
> > around with the conventions to get this simple situation to work as
> > expected.
> >
> > Couldn't you achieve the requested behaviour but without changing the
> > signature of GetPrimaryKeyName by doing this:
> > Conventions.GetPrimaryKeyName = prop => prop.DeclaringType.Name + "Id";
> >
> > Again, sorry if I've misunderstood.
> >
> > Paul Batum
> >
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
