ExtensionMapper enhancement proposal

[Former user]

Implementing populate_instance in an extension mapper give the possibility to extend an instance with new attributes during the populating process. The problem with this method is that it's difficult to use the row parameter to retrieve value from the db since this parameter is in some case a RowProxy and in other case a DictDecorater ('PolymorphicMapper'). To enable an extension to take advantage of value coming from DB to extend the populated instance, I propose to add a new method 'instance_populated'. This method will be called at the end of populate_instance.

[Former user]

patch

[Mike Bayer]

this patch is OK, but i will have to test how much latency is added by another method call for every instance loaded. this is one area of the ORM that is already too slow.

note that the difference between RowProxy and DictDecorator can easily enough be smoothed out by helper objects, since the list of mapped attributes, Columns, and their associations are all known by the mapper. a utility object which acts just like the mapped object itself, proxying requests via the mapper/row would be pretty easy to create, if you can illustrate for me what specific difficulties youre having between RP/DD.

[Former user]

I agree with your idea. Let's me explain to you our problem:

In our application, we have objects for which data's come from 2 repositories.(postgres, ldap) To have a transparent access to the data, we have written an extension mapper. In a first time we have implemented populate_instance to extend the SA data object with attributes coming from ldap. To retrieve these datas, we use a row value named 'dn'. So, when our extension is used on a simple query the following code fit well since the row attribute is a RowProxy:

   dn = row['dn']('dn')

When our extension mapper is used on a polymorphic_union, how can we transparently access to our 'dn' column value? Preceding code raise an AttributeError? (Yes our objects are polymorphic and polymorphisms is alpha :-)

I don't have enough knowledge of the logic that you use to bind aliases columns from a union to the 'real' attribute names of a table.

It's true that using an helper objects to decorate the row attribute received by instance_populate could more efficiently do this job without complicate the initial process.

I hope that my explanation is not too confuse.

If you want to have a look to our application: http://dev.tabellio.org/expedition/browser/branches/ldapsa

[Mike Bayer]

the most portable way to get data from a result row, and the only way to do it from DictDecorator, is to use Column instances instead of strings. both the RowProxy and the DictDecorator are keyed off the same Columns for the mapper which contains the extension:

   dn = row[mappedtable.c.dn](mappedtable.c.dn)

it would be a little too expensive to plug all the possible string names into DictDecorator since those are currently configured per-row. the column itself is best since it links directly back to the original Table object which is represented by the mapper.