<div dir="ltr">Hi Martin,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 6, 2013 at 1:17 AM, Martin Dobias <span dir="ltr"><<a href="mailto:wonder.sk@gmail.com" target="_blank">wonder.sk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Larry<br>
<br>
On Wed, Feb 6, 2013 at 4:25 AM, Larry Shaffer <<a href="mailto:larrys@dakotacarto.com">larrys@dakotacarto.com</a>> wrote:<br>
> Is mFields[i].originIndex (where mFields is a QgsFields vector) the same<br>
> index used for the keys in QgsFieldMap?<br>
<br>
No, it's not the same thing. "originIndex" is a mapping from layer's<br>
attribute indices to provider's indices. That's needed when one or<br>
more fields have been removed in layer's editing mode (and also used<br>
for identification of joined attributes). For example, if you have a<br>
layer with attributes attr1, attr2, attr3 and you decide to delete<br>
attr2, the index of attr3 will change from 2 to 1, but the originIndex<br>
will stay the same. Before new API merge, if an attribute was deleted<br>
in editing mode, indices would not change (because holes were<br>
allowed).<br>
<br>
<br>
> In other words, will this new method, QgsFields::toQgsFieldMap(), function<br>
> correctly [0]? If so, I can use it to attempt to auto-convert<br>
> QgsFieldMap-index-based data defined properties over to field-name-based<br>
> properties, without having think about reintroducing any QgsFieldMap<br>
> functionality at the provider level.<br>
<br>
That wouldn't help, because the numbering of fields has been changed<br>
on provider level (e.g. a provider used to return indices 0,1,3, now<br>
it returns 0,1,2), so I am afraid there's no simple way to establish<br>
mapping of attribute indices from old API providers to new API<br>
providers (because some have changed, others haven't).<br></blockquote><div><br></div><div>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.<br>
<br></div><div>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?<br>
</div><div><br></div><div>Regards,<br></div><div><br>Larry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Regards<br>
<span class=""><font color="#888888">Martin<br>
</font></span></blockquote></div><br></div></div></div>