Enable mr fine grain multi map segment / split control for the api user

[GoogleCodeExporter]

I found cases where i wanted to use the multimap feature but not able and/or 
wanting to change the select to the same "Id" column name to split on.

I solved this by added an optional Func to the MultiMap Query methods for the 
api user which overides the nextSplit index functionality.

I have created i clone with these changes if any one else should found this 
useful. It can be found here:
http://code.google.com/r/mattias-multimap-fine-grain-segment-control/source/

It also solves the issue when there are no "split" columns on the "child" 
types. Common when you want to map record sets with many fields to groups of 
properties (Like Address ie.)

Sample usage (issues seems not to like lt/gt generics but hopefully you get the 
flow):
conn.Query«WorkOrder, Vehicle, Customer, Technician, Location, Booking»(
"SearchVehicleCurrentBookingTechicianLocation @Search",
(workOrder, vehicle, customer, technician, location) =» 
    new Booking
    {
        WorkOrder = workOrder,
        Vehicle = vehicle,
        Customer = customer,
        Technician = technician,
        Location = location
    },
new { Search },
getNextSplitFunc:(reader,splitOn)=»new Queue«int»(
    new []
        {
            reader.GetOrdinal("OrderId"),
            reader.GetOrdinal("VehicleId"),
            reader.GetOrdinal("CustomerId"),
            reader.GetOrdinal("TechnicianId"),
            reader.GetOrdinal("LocationId"),
            reader.FieldCount
        }.Skip(1)
    ).Dequeue
);

Original issue reported on code.google.com by mattias%...@gtempaccount.com on 30 Apr 2011 at 11:37

[GoogleCodeExporter]

Initially I thought we should allow splitOn to accept a comma separated list 
... 

eg: splitOn: "id,ID,LocationId" have it infer any missing splits last specified

Original comment by sam.saff...@gmail.com on 4 May 2011 at 12:05

[GoogleCodeExporter]

If you want an array of strings i rather use an array of strings or an 
enumerable/collection, parsing strings can always open for a can of worms of 
runtime errors that are hard to test for.

Personally an optional Func while keeping the optional splitOn seems more 
flexible, more complex yes, but with great power comes great responsibility…
Having an Id splitOn is great when you have the whole stack because then it’s 
easy to write you’re select to accommodate that.

The problem is when you’re a consultant working against DBA reluctant let 
anyone near his baby, the same problem can occur with legacy systems. Having a 
Func lets you do all kinds of crazy with just a small lambda.

Original comment by mattias%...@gtempaccount.com on 4 May 2011 at 6:15

[GoogleCodeExporter]

splitOn is currently using a string and supports multi mapping, I follow that 
stuff gets complex, but can not see a use case where the splitOn string can not 
be used. 

the Func is fancy and can possibly be reused, but it also feel a bit dangerous

Original comment by sam.saff...@gmail.com on 1 Jun 2011 at 9:22

• Changed state: Done

[GoogleCodeExporter]

Well, "With great power, comes great responsibility", File.Delete() can also 
possibly be dangerous:)
I had a couple of cases that’s why I suggested it and have it in the branch 
I'm using. If something like it would to be implemented in the official source, 
I wouldn’t have to merge with new releases, a bit selfish I know.
The implementation I made supported both splitOn with the standard behavior and 
an optional Func for overriding the default behavior, so both old and new code 
would work.

Basically the sweet deal with a Func is that it gives extensibility without 
having to change the API, you can reuse code easier between types (just have a 
func of t that returns the splitOn func)
You can also solve versioning if production and dev databases give slightly 
different results.

But just that I have a need for it doesn’t mean that anyone else does and 
I’ll respect that.

Original comment by mattias%...@gtempaccount.com on 1 Jun 2011 at 12:01

[GoogleCodeExporter]

I wish there was a way to give you an internal hook without changing the api it 
would make it easier for you 

Original comment by sam.saff...@gmail.com on 2 Jun 2011 at 1:44