James, I'm very supportive of whichever approach you support. In fact, I'm getting very close to checking in changes to #arch which allow one to organize Fluent NHibernate overrides just as easily as class maps without losing the intention and meaning of convention overrides. I will let you know as soon as I check in the changes.
Billy On Feb 9, 3:33 am, James Gregory <[email protected]> wrote: > Billy, it's important to note that I never said you shouldn't be deriving > from AutoMap<T>. If that works for you (or did...) then great. My point is > that this style of modeling has evolved without my knowledge, which is > interesting and concerning at the same time; if it's a good thing then I > have no issue with it, but I can't be seen to endorse it without > understanding the implications of it's use beforehand. > For starters, we have no tests covering this code; which leads us to > situations like this where I manage to break it for people without ever > knowing. We have no examples promoting this style (unless somebody's written > some I wasn't aware of), and as a result we have no way of supporting this > from a guidance perspective. > > My final disagreement with this is that I don't actually like the way it > feels. It looks like a ClassMap, smells like a ClassMap, but is an AutoMap. > You look at it and, unless you already know that it's an AutoMap, think > "where are all the other mappings?" However, that could just be me because > I'd not used it in this manner. > > All that being said, I can definitely see the merit in separating the > overrides into their own classes. People obviously like doing overrides in > the manner that #arch does them, so presuming I can get the code under test > (and fix the bug), I have no issue with people proceeding. > > I've got some time tomorrow working on FNH, so I'll take a look at this > then. > > On Mon, Feb 9, 2009 at 3:16 AM, Billy <[email protected]> wrote: > > > I was also inheriting from AutoMap and ran into the same exception > > with recent updates. The workaround that I've put in place for this > > issue for keeping overrides well organized is described at > > >http://groups.google.com/group/sharp-architecture/msg/c74d493fc74ed98... > > . > > Although it's within the context of S#arp Architecture, it could be > > reused in any project. > > > Billy McCafferty > > > On Feb 3, 12:13 pm, Jimit <[email protected]> wrote: > > > The method MergeWithAutoMapsFromAssembly<T>() seemed to suggest the > > > style I used - that is, subclassing AutoMap<T> in an assembly. It did > > > discover my automaps fine, but then failed with the error described. > > > My domain has some very deep hierarchies and the fluent configuration > > > (using ForTypesThatDeriveFrom<T>) was getting rather wordy so I > > > seperated them into individual subclasses of AutoMap<T> and merged > > > them into my AutoPersistenceModel using > > > MergeWithAutoMapsFromAssembly<T>(). It seemed to work fine, until it > > > didn't. :) I think subclassing AutoMap<T> should be supported, if > > > nothing else than for consistency with ClassMap<T> for non-automapped > > > entities. > > > > Speaking of ForTypesThatDeriveFrom<T>, I think a non-generic overload > > > might come in handy. One use case (that's got me stumped at the moment > > > - having to use reflection) is setting conventions for the open form > > > of a generic base type, e.g EntityBase<,>. In my particular case, I > > > want to ignore certain properties in EntityBase<TEntity,TId> but don't > > > want to have to tell the Automapper to ignore it for each individual > > > TEntity. Any suggestions? > > > On a side note, you mentioned a check-in adding support for mapping > > > generic base classes > > > > On Feb 3, 4:32 pm, James Gregory <[email protected]> wrote: > > > > > Hi, > > > > You seem to be correct in your analysis. The reason this is happening > > is > > > > because it was never intended that people would subclass AutoMap<T>; > > > > alterations to classes are supposed to be done in the > > > > ForTypesThatDeriveFrom<T> call on the automapper, rather than in a > > subclass. > > > > > I realise this is probably quite annoying, but I'm not willing to > > endorse > > > > this style of automapping until I've done some investigation into it's > > > > implications. For the time being, I'd recommend either altering your > > code to > > > > use the recommended ForTypesThatDeriveFrom call, or altering the code > > > > yourself. > > > > > I will make a note to review this style to see if it's something we > > should > > > > officially support. > > > > > James > > > > > On Tue, Feb 3, 2009 at 4:25 PM, Jimit <[email protected]> wrote: > > > > > > Hi, > > > > > Sorry if this comes as a duplicate post. I think google might have > > > > > eaten my first so here it is again. > > > > > First off, mad props to all of you involved in the FNH - it rocks! > > > > > That said, I've come across what seems to be abugin the method > > > > > FindMapping<T> of the AutoPersistenceModel class. Here's a sample > > > > > stack trace: > > > > > > TestCase 'Can_Write_XML_Mapping_Metadata_To_Folder' > > > > > failed: System.Reflection.TargetInvocationException : Exception has > > > > > been thrown by the target of an invocation. > > > > > ----> System.IndexOutOfRangeException : Index was outside the bounds > > > > > of the array. > > > > > at System.RuntimeMethodHandle._InvokeMethodFast(Object target, > > > > > Object > > > > > [] arguments, SignatureStruct& sig, MethodAttributes > > methodAttributes, > > > > > RuntimeTypeHandle typeOwner) > > > > > at System.RuntimeMethodHandle.InvokeMethodFast(Object target, > > Object > > > > > [] arguments, Signature sig, MethodAttributes methodAttributes, > > > > > RuntimeTypeHandle typeOwner) > > > > > at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, > > > > > BindingFlags invokeAttr, Binder binder, Object[] parameters, > > > > > CultureInfo culture, Boolean skipVisibilityChecks) > > > > > at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, > > > > > BindingFlags invokeAttr, Binder binder, Object[] parameters, > > > > > CultureInfo culture) > > > > > at System.Reflection.MethodBase.Invoke(Object obj, Object[] > > > > > parameters) > > > > > at > > > FluentNHibernate.InvocationHelper.InvokeGenericMethodWithDynamicTypeArgumen > > ts > > > > > [T](T target, Expression`1 expression, Object[] methodArguments, Type > > > > > [] typeArguments) > > > > > at > > FluentNHibernate.AutoMap.AutoPersistenceModel.FindMapping(Type > > > > > type) > > > > > at > > FluentNHibernate.AutoMap.AutoPersistenceModel.CompileMappings() > > > > > C:\Projects\Dev\Source\Core\Tests\Unit Tests > > > > > \Core.Infrastructure.Data.NHibernate.Tests\MappingTests.cs(47,0): at > > > Core.Infrastructure.Data.NHibernate.Tests.MappingTests.Can_Write_XML_Mappin > > g_Metadata_To_Folder > > > > > () > > > > > --IndexOutOfRangeException > > > > > at > > > > > FluentNHibernate.AutoMap.AutoPersistenceModel.<FindMapping>b__7[T] > > > > > (IMapping t) > > > > > at System.Collections.Generic.List`1.Find(Predicate`1 match) > > > > > at > > FluentNHibernate.AutoMap.AutoPersistenceModel.FindMapping[T]() > > > > > > The test above simply instantiates a new AutoPersistenceModel, calls > > > > > MergeWithMappingsFromAssembly<T>() to add some custom mappings > > > > > (classes inheriting from Automap<T>), calls CompileMappings() and > > > > > attempts to write them to a folder using WriteMappingsTo(). > > > > > > I believe the culprit is this line in FindMapping<T>: > > > > > > // standard AutoMap<T> not found for the type, so looking > > > > > for one for it's base type. > > > > > return (IClassMap)_mappings.Find(t => t.GetType > > > > > ().GetGenericArguments()[0] == typeof(T).BaseType); > > > > > Because _mappings contains instances of classes that are derivatives > > > > > of AutoMap<T> and aren't actually generic types, the array returned > > > > > from Type.GetGenericArguments() contains no elements and thus you get > > > > > the IndexOutOfRangeException. > > > > > > I think the solution is to modify the predicate to allow for none > > > > > generic types by casting to Automap<T> first. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group. 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/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
