Enhanced and fixed late-binding of variants for Delphi XE2 and up

For several units of our framework, we allow late-binding of data values, using a variant and direct named access to properties:
- In SynCommons, we defined our TDocVariant custom variant type, able to store any JSON/BSON document-based content;
- In SynBigTable, we use the TSynTableVariantType custom variant type, as defined in SynCommons;
- In SynDB, we defined a TSQLDBRowVariantType, ready to access any column of a RDBMS data result set row;
- In mORMot, we allow access to TSQLTableRowVariantType column values.

It's a very convenient way of accessing result rows values. Code is still very readable, and safe at the same time.

For instance, we can write:

var V: variant;
 ...
  TDocVariant.New(V); // or slightly slower V := TDocVariant.New;
  V.name := 'John';
  V.year := 1972;
  // now V contains {"name":"john","year":1982}

This is just another implementation of KISS design in our framework.

Since Delphi XE2, some modifications were introduced to the official DispInvoke() RTL implementation:

A new varUStrArg kind of parameter has been defined, which will allow to transmit UnicodeString property values;
All text property values would be transmitted as BSTR / WideString / varOleStr variants to the invoked variant type;
All textual property names were normalized to be in UPPERCASE.

Those modifications are worth considering...
And we may have discovered two regressions: one about speed, and the other about an unexpected logic bug...

The issues

The first modification does make sense, and was indeed a welcome fix for an Unicode version of Delphi. It should have been as such since Delphi 2009.

Temporary conversion to WideString does make sense in the COM / OLE world, but is an awfull performance bottleneck in the pure Delphi realm, i.e. when using late-binding with custom type of variants (as for all our custom variant types). This may be a noticeable speed penalty, in comparison to previous versions of the compiler.

Last but not least, the conversion to uppercase is a bug. For instance, the following code won't work as expected since Delphi XE2:

var V: variant;
 ...
  TDocVariant.New(V); // or slightly slower V := TDocVariant.New;
  V.name := 'John';
  V.year := 1972;
  // before Delphi XE2, V contains {"name":"john","year":1982} - as expected
  // since Delphi XE2,  V contains {"NAME":"john","YEAR":1982} - sounds like a bug, doesn't it?

This sounds indeed like an awfull regression.

Fix included in the mORMot framework

Since revision 1.18 of the framework, the patch described in this previous blog article has been modified for Delphi XE2 and up, as such:

It will handle varUStrArg kind of parameter as exepcted;
It will avoid any temporary conversion to WideString for textual values;
It will by-pass the property name change into uppercase.

As soon as you define SynCommons in any of your program's uses class, our hooked DispInvoke() will take place, and identify any of our TSynInvokeableVariantType classes.

As a result, it will by-pass the performance bottleneck of the default RTL implementation, and also fix the uppercase conversion of the property name.

Of course, if this variant is not a TSynInvokeableVariantType instance (e.g. any Ole Automation call), the regular TInvokeableVariantType.DispInvoke() method as defined in Variants.pas will be executed, to maintain the best compatibility possible.

Feedback is welcome in our forum, as usual!

Synopse Open Source