James, Yes, I am using AutoMapping. After a glimpse on the trunk source code, I've found that on AutoMapper.cs, line 35, the convention is hard-coded. What happens is, given that I now have my set of conventions, it generates a subclass with 2-key foreign key, instead of just one. I am not sure, but I think that's because the foreign key name resultant from my conventions are different of what's stated on AutoMapper.cs file.
Thanks, Adriano On Mar 12, 10:40 am, James Gregory <jagregory....@gmail.com> wrote: > I'm not sure what you mean, are you using automapping? > > On Thu, Mar 12, 2009 at 12:58 PM, Adriano Machado <adriano.mach...@gmail.com > > > wrote: > > > James, > > > Regarding inheritance and subclasses, how do I define the convention > > for the primary key of the subclasses? > > > On Mar 11, 8:22 pm, James Gregory <jagregory....@gmail.com> wrote: > > > Sounds good, I'm out tomorrow but I'm free all weekend so I'll try to > > catch > > > you then. > > > > On Wed, Mar 11, 2009 at 10:07 PM, Paul Batum <paul.ba...@gmail.com> > > wrote: > > > > Nice work James. I see you implemented shortcuts, they look nice. > > > > > Now, lets have a chat about getting this into the semantic model > > branch... > > > > :) > > > > > On Thu, Mar 12, 2009 at 8:39 AM, James Gregory < > > jagregory....@gmail.com>wrote: > > > > >> ...and it's committed! *Hides from the angry mob of devs with broken > > > >> builds* > > > >> The wiki has been updated with the new syntax, as well as with some > > > >> dedicated pages to conventions. > > > > >> - Conventions <http://wiki.fluentnhibernate.org/show/Conventions> > > > >> - Convention Interfaces< > >http://wiki.fluentnhibernate.org/show/ConventionsInterfaces> > > > > >> - Convention Shortcuts< > >http://wiki.fluentnhibernate.org/show/ConventionsShortcuts> > > > > >> - Converting to new style conventions< > >http://wiki.fluentnhibernate.org/show/ConvertingToNewStyleConventions> > > > > >> - Conventions behind-the-scenes< > >http://wiki.fluentnhibernate.org/show/ConventionsCode> > > > > >> On Wed, Mar 4, 2009 at 9:06 PM, Paul Batum <paul.ba...@gmail.com> > > wrote: > > > > >>> As James mentioned, he and I have already discussed the topic of new > > > >>> conventions + semantic model. I really don't think its going to be a > > > >>> problem. Obviously, the inner machinery that makes James' conventions > > work > > > >>> will change when we move to the semantic model, but our users will be > > > >>> isolated from this. > > > > >>> On Thu, Mar 5, 2009 at 3:32 AM, James <james.freiwi...@gmail.com> > > wrote: > > > > >>>> Sounds excellent. > > > > >>>> On Mar 4, 8:10 am, James Gregory <jagregory....@gmail.com> wrote: > > > >>>> > Guys, > > > > >>>> > This email is a heads up, with an opportunity to provide feedback > > > >>>> before I > > > >>>> > commit these changes to trunk. I want to make it clear that I'm > > not > > > >>>> bashing > > > >>>> > the work of the developers before myself who wrote the original > > > >>>> conventions > > > >>>> > code. I mean no disrespect, it's just not my idea of where it > > should > > > >>>> > proceed. > > > > >>>> > Our current implementation of conventions is pretty > > unmaintainable, > > > >>>> it's > > > >>>> > merely a large class with several lambda functions that get called > > at > > > >>>> > various stages in the mapping generation. Our mapping generation > > code > > > >>>> has > > > >>>> > logic for the conventions strewn about, and the convention > > functions > > > >>>> > themselves are pretty awkward for anything other than really basic > > > >>>> things > > > >>>> > (once logic starts coming in, then the inline lambdas break down). > > > >>>> There's > > > >>>> > also no graceful degredation for support, we either support a > > > >>>> convention or > > > >>>> > we don't, there's very little room for people to work around > > missing > > > >>>> > features, which is putting a lot of strain on future development. > > > >>>> Finally, > > > >>>> > when you're overriding a lot of conventions, your convention code > > can > > > >>>> > quickly become large and cumbersome - there's no SoC. > > > > >>>> > Those are my reasons for what I've been working on - a complete > > > >>>> rewrite of > > > >>>> > the conventions code. > > > > >>>> > So how has it changed? The Conventions class has gone, for > > starters; > > > >>>> which > > > >>>> > means the inline overriding of conventions is gone too. Instead > > what > > > >>>> you > > > >>>> > have is a series of interfaces of varying degrees of granularity; > > any > > > >>>> > classes implementing any of the interfaces will be automagically > > > >>>> hooked into > > > >>>> > FNHs generation cycle. What this equates to is you'll have a > > > >>>> > folder/namespace dedicated to convention overrides, each class in > > > >>>> there > > > >>>> > making an alteration to the conventions when it's called. Because > > the > > > >>>> > conventions are defined as interfaces, that means you can have a > > > >>>> single > > > >>>> > class handle multiple conventions of the same kind too. > > > > >>>> > An example or two: > > > > >>>> > public class TableNameConvention : IClassConvention > > > >>>> > { > > > >>>> > public bool Accept(IClassMap classMap) > > > >>>> > { > > > >>>> > return classMap.EntityType.IsSubclassOf(typeof(Customer)); > > > >>>> > } > > > > >>>> > public void Apply(IClassMap classMap) > > > >>>> > { > > > >>>> > classMap.WithTable("Customer_" + classMap.EntityType.Name); > > > >>>> > } > > > > >>>> > } > > > > >>>> > public class ColumnNameConvention : IPropertyConvention, > > IIdConvention > > > >>>> > { > > > >>>> > public bool Accept(IProperty property) > > > >>>> > { > > > >>>> > return true; > > > >>>> > } > > > > >>>> > public bool Accept(IIdentityPart id) > > > >>>> > { > > > >>>> > return true; > > > >>>> > } > > > > >>>> > public void Apply(IProperty property) > > > >>>> > { > > > >>>> > var column = GetColumnName(property.Property); > > > > >>>> > property.ColumnName(column); > > > >>>> > } > > > > >>>> > public void Apply(IIdentityPart id) > > > >>>> > { > > > >>>> > var column = GetColumnName(id.Property); > > > > >>>> > id.ColumnName(column); > > > >>>> > } > > > > >>>> > private string GetColumnName(PropertyInfo prop) > > > >>>> > { > > > >>>> > return prop.Name.ToLower(); > > > >>>> > } > > > > >>>> > } > > > > >>>> > I'm very aware that these conventions are more verbose than our > > > >>>> existing > > > >>>> > ones, but the power and SoC is uncomparable. > > > > >>>> > The setup has now been reduced to: > > > > >>>> > WithConventions(conventions => > > > >>>> > conventions > > > >>>> > .Add<TableNameConvention>() > > > >>>> > .Add<ColumnNameConvention>()); > > > > >>>> > or simply: > > > > >>>> > WithConventions(conventions => > > > >>>> > conventions.AddFromAssemblyOf<ColumnNameConvention>()); > > > > >>>> > Which could actually be changed to implicitly find any conventions > > in > > > >>>> the > > > >>>> > same assembly as your mappings, but that's another discussion. > > > > >>>> > The interfaces you're provided with currently are: > > > > >>>> > - IAssemblyConvention - Applied to an IEnumerable of IClassMap > > from > > > >>>> each > > > >>>> > assembly > > > >>>> > - IClassConvention - Applied to each IClassMap > > > >>>> > - IMappingPartConvention - Applied to every mapping part in a > > > >>>> IClassMap > > > >>>> > - IPropertyConvention - Applied to Map/Property's > > > >>>> > - IIdConvention - Ids > > > >>>> > - IVersionConvention - Versions > > > >>>> > - IComponentConvention & IDynamicComponentConvention - > > Components > > > >>>> > - IRelationshipConvention - Applied to all relationships > > > >>>> > - IHasManyConvention, IHasManyToManyConvention, > > IHasOneConvention, > > > >>>> > IReferenceConvention > > > >>>> > - Applied to each relationship > > > >>>> > - IUserTypeConvention & UserTypeConvention base - For use with > > > >>>> IUserTypes > > > >>>> > - IJoinConvention - Applied to joined tables > > > >>>> > - AttributePropertyConvention - Applied to properties with > > > >>>> attributes > > > > >>>> > As you can see, there are a fair few options available. If we add > > a > > > >>>> new > > > >>>> > feature but forget to provide an interface for a convention, > > there's > > > >>>> always > > > >>>> > the level above instead. If IPropertyConvention didn't exist for > > > >>>> example, > > > >>>> > you could easily just implement IMappingPartConvention and write > > the > > > >>>> Accept > > > >>>> > method to only accept properties. > > > > >>>> > I suppose I'm asking if anyone has any major objections to these > > > >>>> changes? > > > >>>> > Are you ok with losing the simplicity of overriding one or two > > > >>>> conventions > > > >>>> > inline, for the net gain of more power? > > > > >>>> > James --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
