On Wed, Feb 6, 2013 at 10:20 AM, Larry Shaffer <[email protected]> wrote: > Thanks for the explanation. Figured it wouldn't be that simple. So, is it > worth the effort to fix this (the 1.8 to 2.0 index issue)? I think many > users will find manually updating their data defined mappings, for every > layer in a project that has them, very annoying. This has the potential to > become a very large time-sucking problem for many users.
As far as I know, it should be a problem only in data-defined new labeling - field names are used in other places. > Could a lightweight QHash<old index, field name> be populated inline with > the current building of the attribute vectors; only for those providers that > would be different than before? The only-used-for-reads QHash could be used > to create an auto-update routine for data defined mappings. Is something > like that reasonable to implement? Is there another approach, or any at all? I think a real problem is there just with postgis layers - if I'm not wrong, the holes in 1.x are appearing when geometry column is not at the end of the list of fields, so for a layer with columns geom, attr1, attr2 you would get attribute indices 1,2. As you can see, implementing such mapping would be dependent on table structure. The problem is that the stored indices get broken even with a change of table structure - so even if we implemented some backward compatibility for postgis (that would take table structure into account), it might still cause problems. Martin _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
