Create() and Fetch() routing to Create(Object) and Fetch(Object)

Create() and Fetch() routing to Create(Object) and Fetch(Object)

Old forum URL: forums.lhotka.net/forums/t/711.aspx


tsmo posted on Monday, July 24, 2006

Is it a bug or a design decision that when you try to call DataPortal.Create() and DataPortal.Fetch() you end up actually being routed to DataPortal.Create(Object) and DataPortal.Fetch(Object)?

I was able to fix this by making the following changes to MethodCaller.cs.  Your milage may vary, it's not as pretty as it could be, but it works for my usage patterns.  Anyway:

line 62, insert:

if (parameters.Length == 1 && parameters[0] == null)
    parameters = Type.EmptyTypes;

line 90-91, replace:

if (item == null)
    types.Add(typeof(object));

with

if (item == null)
    continue;

line 99, replace:

result = FindMethod(objectType, method, types.ToArray());

with

if (types.Count > 0)
    result = FindMethod(objectType, method, types.ToArray());

line 104, replace:

result = FindMethod(objectType, method, parameters.Length);

with

result = FindMethod(objectType, method, types.Count);

Thanks,
tsmo

RockfordLhotka replied on Monday, July 24, 2006

It is by design (sort of).

If you look in the book you'll see that the implementation there is different from the current implementation. When I updated the code to allow DataPortal.Fetch<T>(), I did so in a way that minimized breaking changes on existing code. Unfortunately this isn't really ideal, because it means that such calls route to DataPortal_XYZ(object) rather than DataPortal_XYZ().

The fix isn't actually in MethodCaller btw, but rather in the data portal itself, where it forces at least Nothing/null to be passed as a parameter. What SHOULD happen is that literally nothing should be passed (not null or Nothing, but nothing) Big Smile [:D]

That would still require a fix to MethodCaller, since it hasn't been tested for the case where no parameters are passed at all - since that can't actually happen at the moment...

The thing is, I can't make this change without breaking potentially unknown amounts of existing code. Sad [:(]  In any case, it isn't the kind of thing that can be done in a 2.0.x release, as those are bug-fix releases.

I am thinking about making this change to 2.1. But I hesitate, because a breaking change of this magnitude is non-trivial. Many (most?) people would have to touch virtually every root class if I make this change - because it would mean the normal call to DataPortal.Create() would route to DataPortal_Create() instead of DataPortal_Create(object).

Very tricky...

Copyright (c) Marimer LLC