Row._mapping is not a drop-in replacement for Row's deprecated Mapping behavior

[ugtar]

To align with sqlalchemy >=1.4, Row's .keys() and .values() methods produce a warning like

DeprecationWarning: The `Row.keys()` method is deprecated to mimic SQLAlchemy behaviour, use `Row._mapping.keys()` instead.

Row's .__getitem__() method on the other hand doesn't produce any such warning. In the case of Sqlalchemy the intent is clear to deprecate Row's mapping behavior entirely in favor of Tuple-like member access, but it's not clear what the intent is in Databases.

If the intent in Databases is to follow suit, then one would expect to be able to replace the old row["foo"] access with row._mapping["foo"] (ignoring for now Tuple-like attribute access). But, this doesn't work properly, because Row's ._mapping attribute simply returns the driver's result object (which happens to have Mapping behavior), but it does not process the value the same way that .__getitem__() does. For example with a json column, row["foo"] will return a deserialized python object like {'some': 'thing'}, while row._mapping["foo"] returns a string '{"some": "thing"}'.

I would like to update my code, but I feel a bit caught between a rock and a hard place...

Edit: the "processing" in __getitem__() I'm referring to is this:

        raw = self._row[idx]
        processor = datatype._cached_result_processor(self._dialect, None)

        if processor is not None:
            return processor(raw)
        return raw