And what prevent you from using the declaring type for that? On Fri, Dec 12, 2008 at 9:52 AM, Chris Marisic <chrismari...@hotmail.com>wrote:
> > Ayende, the issue I brought up is GetPrimaryKeyName is based off > Func<PropertyInfo, string>, this makes sense for regular mapping since > the mapping classes Id(x=x.AddressID) which when it reads > GetPrimaryKey by default it returns Prop.Name in this case > "AddressID". > > With auto mapping, the rather standard convention in databases is to > have Table Address, PK AddressID, so if you do > AutoPersistanceModel.WithConvention(conv=>conv.GetPrimaryKeyName => > prop.Name + "ID") instead of getting select AddressID, you actually > get select IdID. > > Paul that sounds like a good solution, or just perhaps adding another > fluent method to autoperisistance like .PrimaryKeyStartsWithTypeName > (true/false) and leave it up to people to only specifically use the > convention support if they need some unusual case like > prop.ReflectedType + "PrimaryKeyID" and just have an example for that > on the wiki eventually. > > On Dec 12, 9:29 am, "Ayende Rahien" <aye...@ayende.com> wrote: > > Sorry to jump in the middle, but what exactly is the problem? > > > > On Fri, Dec 12, 2008 at 9:25 AM, Paul Batum <paul.ba...@gmail.com> > wrote: > > > Fair enough. What if the AutoPersistenceModel simply initializes the > > > Convention to use declaring/reflected type? > > > > > On Sat, Dec 13, 2008 at 12:25 AM, Chris Marisic < > chrismari...@hotmail.com>wrote: > > > > >> It just seems like it would be really unintuitive which adds alot of > > >> friction to automapping since even if your objects were perfect 1 to 1 > > >> mappings of your database tables except the Id column on your tables > > >> includes the table name I think a person that would try FH would > > >> become really frustrated for not being able to figure out how to map > > >> the PK to be Type+"ID" unless it was somehow said very clearly or they > > >> have done alot of work using PropertyInfo's to immediately think I can > > >> resolve it up to the type of the object. But even with that, they > > >> would need to try to figure out what the PropertyInfo actually even is > > >> for PK. It just seems like there needs to be a more intuitive way > > >> otherwise I'd be willing to bet you will see this question brought up > > >> for the entire duration of FH. > > > > >> On Dec 11, 9:56 pm, "Paul Batum" <paul.ba...@gmail.com> wrote: > > > > >> > 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? > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
