Hi James I've not read the whole thread, so forgive me if I'm going in the wrong direction. However let me shed some light on this, looks like some users of the library are inheriting from AutoMap and using the model.addMappingsFromAssembly( ); method. This is in-fact the very first way I wrote automappings, until Chad showed me the light to the fluent method. However if your doing alot of custom mappins then loading in via seperate classes is a lot cleaner than the 80 lins of fluent code I have in one of my projects (yuk).
Hope you this puts you in the picture as how this has come about. Andy On Feb 9, 10: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 -~----------~----~----~----~------~----~------~--~---
