Hi Paul
First patch applied.
Cheers
Andy
On Wed, Aug 27, 2008 at 11:21 PM, Paul Batum <[EMAIL PROTECTED]> wrote:
> Yeah I wanted a few tests specifically for the method on InvocationHelper.
>
>
> On Wed, Aug 27, 2008 at 9:57 PM, Andrew Stewart <
> [EMAIL PROTECTED]> wrote:
>
>> Hi Paul
>>
>> There's a bunch of integration test's running over that series of code,
>> which would test it from an automapping perspective. Maybe worth creating
>> some a little more specific though.
>>
>> Cheers
>>
>> Andy
>>
>> On Wed, Aug 27, 2008 at 9:51 PM, Paul Batum <[EMAIL PROTECTED]> wrote:
>>
>>> Cool. I was a bit lazy and didn't write any tests for that code, I would
>>> like to go back and add a few once the patch is applied.
>>>
>>>
>>> On Wed, Aug 27, 2008 at 1:05 PM, Andrew Stewart <
>>> [EMAIL PROTECTED]> wrote:
>>>
>>>> Hi Paul
>>>>
>>>> I will be applying your patch as the first fix for the problem, however
>>>> I've just not had any time yet. I may at somepoint look for a larger
>>>> refactoring, but I think one way or another dropping down your method will
>>>> be essential at somepoint in the process.
>>>>
>>>> Cheers
>>>>
>>>> Andy
>>>>
>>>> On Tue, Aug 26, 2008 at 9:04 PM, Paul Batum <[EMAIL PROTECTED]>wrote:
>>>>
>>>>> Hey Andy,
>>>>>
>>>>> I was wondering if you have decided where to go with this code? I
>>>>> thought my patch would be a good option if you don't want to engage in a
>>>>> larger refactoring.
>>>>>
>>>>> Paul Batum
>>>>>
>>>>>
>>>>> On Sun, Aug 17, 2008 at 6:20 PM, Paul Batum <[EMAIL PROTECTED]>wrote:
>>>>>
>>>>>> Hey Andy,
>>>>>>
>>>>>> I decided to tackle your problem from a different angle to Chad. It
>>>>>> sounds like Chad went to the root of the problem by making non generic
>>>>>> methods. I came up with a less fragile way of invoking the generic
>>>>>> methods
>>>>>> using reflection. My solution replaces this:
>>>>>>
>>>>>> // Merge Mappings together
>>>>>> var findAutoMapMethod = typeof(AutoMapper).GetMethod("MergeMap");
>>>>>> var genericfindAutoMapMethod =
>>>>>> findAutoMapMethod.MakeGenericMethod(obj);
>>>>>> genericfindAutoMapMethod.Invoke(autoMap, new[] { mapping });
>>>>>>
>>>>>> With this:
>>>>>>
>>>>>> InvocationHelper.InvokeGenericMethodWithDynamicTypeArguments(
>>>>>> autoMap, a => a.MergeMap<object>(null), new[] {
>>>>>> mapping }, obj);
>>>>>>
>>>>>> Here is the implementation of that method:
>>>>>>
>>>>>> public static object
>>>>>> InvokeGenericMethodWithDynamicTypeArguments<T>(T target,
>>>>>> Expression<Func<T,
>>>>>> object>> expression, object[] methodArguments, params Type[]
>>>>>> typeArguments)
>>>>>> {
>>>>>> var methodInfo = ReflectionHelper.GetMethod(expression);
>>>>>> if (methodInfo.GetGenericArguments().Length !=
>>>>>> typeArguments.Length)
>>>>>> throw new ArgumentException(
>>>>>> string.Format("The method '{0}' has {1} type
>>>>>> argument(s) but {2} type argument(s) were passed. The amounts must be
>>>>>> equal.",
>>>>>> methodInfo.Name,
>>>>>> methodInfo.GetGenericArguments().Length,
>>>>>> typeArguments.Length));
>>>>>>
>>>>>> return methodInfo
>>>>>> .GetGenericMethodDefinition()
>>>>>> .MakeGenericMethod(typeArguments)
>>>>>> .Invoke(target, methodArguments);
>>>>>> }
>>>>>>
>>>>>> This is sturdier because a refactoring of the MergeMap method would
>>>>>> flow to the lambda. Obviously it is still somewhat fragile because there
>>>>>> is
>>>>>> no guarantee that the right number of type arguments is passed, hence the
>>>>>> runtime check.
>>>>>>
>>>>>> The patch is attached to this email. I figure that you will probably
>>>>>> want to go down the path that Chad followed, but perhaps this
>>>>>> implementation
>>>>>> will be useful trick when you don't have the luxury of modifying the API
>>>>>> to
>>>>>> be non-generic.
>>>>>>
>>>>>> Paul Batum
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Aug 17, 2008 at 3:28 PM, Andrew Stewart <
>>>>>> [EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>> Hi Chad
>>>>>>>
>>>>>>>
>>>>>>>> Will this be called directly by people, or is this mostly internal
>>>>>>>> API stuff?
>>>>>>>
>>>>>>>
>>>>>>> The crappy code is only internal and tests should now fail if it's
>>>>>>> broken, which is nice to know. I think I know what you mean and I'll
>>>>>>> try and
>>>>>>> tidy that code up shortly, thanks for the offer to pair over this it may
>>>>>>> come in useful, but i'd like to have a go at it myself for now. I'll
>>>>>>> give
>>>>>>> you a shout if I get stuck though, if it's ok with you.
>>>>>>>
>>>>>>> Cheers
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Aug 16, 2008 at 1:02 AM, Chad Myers <[EMAIL PROTECTED]>wrote:
>>>>>>>
>>>>>>>> I did a spike and got my head around it. Basically, you have a
>>>>>>>> bunch of generic methods and then you're treating them non-generically.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Will this be called directly by people, or is this mostly internal
>>>>>>>> API stuff?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I was able to create an IAutoMap rather than have AutoMap<T>,
>>>>>>>> IAutoPartMapper instead of the various part mappers (IAutoMapper was
>>>>>>>> confusing because there's an AutoMapper<T>, but it wasn't an
>>>>>>>> IAutoMapper,
>>>>>>>> IAutoMapper is really something like IAutoPartMapper, etc).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Anyhow, if you use interfaces for these things and make them
>>>>>>>> non-generic (i.e. don't make it Foo<T>, just make methods like Foo(Type
>>>>>>>> theType)).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Make the people-facing fluent interfaces generic <T>, but all the
>>>>>>>> internal stuff non-generic otherwise your life will be very painful (as
>>>>>>>> you've already found out).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't want to commit my spike code because it's not tested and
>>>>>>>> it's sloppy, but maybe we can pair on this sometime if you want, or if
>>>>>>>> you
>>>>>>>> want to research this yourself, etc.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -c
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> *From:* fluent-nhibernate@googlegroups.com [mailto:
>>>>>>>> [EMAIL PROTECTED] *On Behalf Of *Andrew Stewart
>>>>>>>> *Sent:* Friday, August 15, 2008 7:51 AM
>>>>>>>> *To:* fluent-nhibernate@googlegroups.com
>>>>>>>> *Subject:* [fluent-nhib] Re: Ayende on Fluent nHibernate - AutoMap
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hello
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I've just checked this in and it seems to work,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> var persistenceModel = new
>>>>>>>> AutoPersistenceModel(Assembly.GetAssembly(typeof(PlotMap)));
>>>>>>>> persistenceModel.AddEntityAssembly(Assembly.GetAssembly(typeof
>>>>>>>> (Address)), t => (t.Namespace == "Mdis.Entities" && ( t.BaseType ==
>>>>>>>> typeof(object))));
>>>>>>>> persistenceModel.Configure(cfg);
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The first assembly is the assembly containing your maps, the second
>>>>>>>> is the assembly containing your entities (I'm assuming you have two
>>>>>>>> assemblies for SoC, but there's no reason why these can't be the
>>>>>>>> same). Then
>>>>>>>> I've created an AutoMap which inherits from ClassMap, this is so I
>>>>>>>> don't
>>>>>>>> dirty up the base class with my little requirements, essentially what
>>>>>>>> properties have already been mapped(to prevent duplication).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Example
>>>>>>>>
>>>>>>>> public class PlotMap : AutoMap<Plot>
>>>>>>>> {
>>>>>>>> public PlotMap()
>>>>>>>> {
>>>>>>>> HasManyToMany<Service>(p => p.Services);
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> What happens is, first it loads in your automap's then in maps in
>>>>>>>> extra unmapped properties and entities(hope that makes sense). So you
>>>>>>>> only
>>>>>>>> need to specify exceptions to the rule everything else will be mapped
>>>>>>>> straight out the box as if by magic. Now my next challenge will be
>>>>>>>> making
>>>>>>>> this a bit more fluent and specifying conventions across the board as
>>>>>>>> of
>>>>>>>> Chad's suggestion below:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> var model = AutoPersistenceModel
>>>>>>>> .MapEntitiesFromAssemblyOf<AutoMapTests>()
>>>>>>>> .Where(t => t.Namespace == "FluentNHibernate.AutoMap.Test")
>>>>>>>> .ForTypesThatDeriveFrom<DomainEntity>(map =>
>>>>>>>> {
>>>>>>>>
>>>>>>>> map.UseIdentityForKey(e => e.Id, "Id");
>>>>>>>> });
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Plus if anyone can think of a nice way to replace the contents of
>>>>>>>> AutoPersistanceModel.AddEntityAssembly, which strict typing let me
>>>>>>>> know.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hope you like it, so far.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Andy
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fluent-nhibernate?hl=en
-~----------~----~----~----~------~----~------~--~---
