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