Hi Martin, On Wed, Feb 6, 2013 at 1:17 AM, Martin Dobias <[email protected]> wrote:
> Hi Larry > > On Wed, Feb 6, 2013 at 4:25 AM, Larry Shaffer <[email protected]> > wrote: > > Is mFields[i].originIndex (where mFields is a QgsFields vector) the same > > index used for the keys in QgsFieldMap? > > No, it's not the same thing. "originIndex" is a mapping from layer's > attribute indices to provider's indices. That's needed when one or > more fields have been removed in layer's editing mode (and also used > for identification of joined attributes). For example, if you have a > layer with attributes attr1, attr2, attr3 and you decide to delete > attr2, the index of attr3 will change from 2 to 1, but the originIndex > will stay the same. Before new API merge, if an attribute was deleted > in editing mode, indices would not change (because holes were > allowed). > > > > In other words, will this new method, QgsFields::toQgsFieldMap(), > function > > correctly [0]? If so, I can use it to attempt to auto-convert > > QgsFieldMap-index-based data defined properties over to field-name-based > > properties, without having think about reintroducing any QgsFieldMap > > functionality at the provider level. > > That wouldn't help, because the numbering of fields has been changed > on provider level (e.g. a provider used to return indices 0,1,3, now > it returns 0,1,2), so I am afraid there's no simple way to establish > mapping of attribute indices from old API providers to new API > providers (because some have changed, others haven't). > 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. 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? Regards, Larry > Regards > Martin >
_______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
