Workaround instance method call on null object issue in IMDB providers

[GoogleCodeExporter]

There are instance methods like string.ToLower(), that fail if this==null
inside them on IMDB, but do not fail on SQL. Obviously, the behavior must
be the same everywhere. So we must fix this.

Possible approach:
- Use our MemberCompilerProvider to replace these methods to our own ones
(static) performing null check first.

Note that this won't lead to absolutely the same behavior as in SQL: SQL
analogues of such methods return NULL in this case, but we can return only
false or true.

So any other ideas are welcome.

Original issue reported on code.google.com by alex.yakunin on 8 Sep 2009 at 10:06

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Workaround for string type: try using the code below instead of 
myString.MethodCall:
- (myString ?? string.Empty).MethodCall 
- myString==null ? resultForNull : myString.MethodCall

Original comment by alex.yakunin on 21 Oct 2009 at 11:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

One more note: expected behavior in LINQ to Enumerable in this case is 
exception. We 
could achieve the same with our LINQ to SQL, but that's completely different to 
what 
people used to see there, and other ORM tools follow this way:
- something like NULL.MethodCall in SQL is NULL 
  (in fact, it is always MethodCall(NULL, ...) there)
- null.MethodCall in .NET leads to an exception. But we're going to replace its 
result to some "acceptable" answer for IMDB - e.g. 0 for string.Length and so 
on. 

Note that likely it's a bad idea to return "nullable" null there. We could 
return 
Nullable<T> instead of T in all such cases and utilize its Value later, but 
this will 
lead to completely crazy result code:

Original expression: 
  str.Length==true ? "T" : "F";
Translated expression (pseudo-code to reduce the complexity): 
  let lengthExpr = str==null ? (int?)null : str.Length
  let eqExpr = lengthExpr.HasValue ? (bool?) lengthExpr.Value==true : null
  return eqExpr.HasValue ? (eqExpr.Value ? "T" : "F") : null;

To understand the complexity of result, try to "explode" eqExpr and lengthExpr 
there. 
There must be 8 usages of str instead of one in original code.

So likely, any fix here will be a workaround: NULL in SQL and nullable types in 
.NET are quite different.

Btw... I hate the person who invented such NULL handling in SQL.

Original comment by alex.yakunin on 21 Oct 2009 at 12:17

[GoogleCodeExporter]

Original comment by alexis.k...@gmail.com on 9 Feb 2010 at 1:58

• Added labels: Milestone-Future