Bug report #2629

fTools fail to rename duplicated field names if they are 10 char long

Added by Borys Jurgiel over 10 years ago. Updated over 10 years ago.

Status:Closed
Priority:Low
Assignee:cfarmer -
Category:Python plugins
Affected QGIS version: Regression?:No
Operating System:All Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:12689

Description

If I join two tables containing common 10-char-long field name, fTools try to add the "_" char to one of them, then truncate it and fail to write, with no warning message. Could it rename the field name in a more robust way or at least warn that the layer won't be created and why?

add_warnings.diff Magnifier - proposed patch (7.33 KB) Alexander Bruy, 2010-04-14 12:25 AM

trim_and_warnings.diff Magnifier (7.7 KB) Alexander Bruy, 2010-04-14 01:55 AM

History

#1 Updated by Borys Jurgiel over 10 years ago

I've just realized it's a common issue in all fTools.

#2 Updated by Alexander Bruy over 10 years ago

This is not an fTools issue, this is limitation of ESRI Shapefile format (exactly DBF format). Field name must be <= 10 characters.

Here is patch to add some warnings to the "Join by attributes" and "Spatial join" tools

#3 Updated by Borys Jurgiel over 10 years ago

The warnings are necessary, but I still suggest to truncate names to 8 characters before adding the suffix. It's extremely easy to implement and can help in many cases (not in all, of course).

#4 Updated by Alexander Bruy over 10 years ago

Ok, here is another patch. Long names are truncated to 8 characters and then suffix added. But in this case warning are not necessary I think and we can remove it.

#5 Updated by Borys Jurgiel over 10 years ago

They're still necessary, as one can have more than 2 affected fields. E.g. both "foobarfoo1" and "foobarfoo2" in both tables. It would be the best to add a computed suffix _(n+1) (thought it's still not ideal, as it could cause confusions)

#6 Updated by Alexander Bruy over 10 years ago

Replying to [comment:6 borysiasty]:

It would be the best to add a computed suffix _(n+1) (thought it's still not ideal, as it could cause confusions)

As far as I see computed suffixes _(n+1) are used

#7 Updated by Borys Jurgiel over 10 years ago

Sorry, my fault! I've look too briefly into the code!

Anyway, I believe we should keep the warnings for a case if one has more than 9 very long names with common prefix in a non-dbf table (e.g. fobarfoo_temperature, fobarfoo_precipitation etc).

#8 Updated by cfarmer - over 10 years ago

  • Resolution set to fixed
  • Status changed from Open to Closed

Patch applied in 71a9f815 (SVN r13314).

Carson

Also available in: Atom PDF