Feature request #11485

copy string attribute into another one changes the length of the target column

Added by Fabien Cerbelaud about 10 years ago. Updated over 9 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Documentation and Help
Pull Request or Patch supplied:No Resolution:
Easy fix?:No Copied to github as #:19755

Description

Hi, I try to create a new column type string with fields calculators, I choose 2 for length of this column (named "tata") but when I upload this fields with another string column (named "bibi") wich have a length of 5 for example. I find 5 characters in column "tata". Even if in properties the type of "tata" is string and length 2. I try this in 2.2 and 2.4 version and the result is the same.

___
bibi | tata |
87004| 87004|

bug_screenshot.jpg (885 KB) Fabien Cerbelaud, 2014-10-24 02:44 AM

History

#1 Updated by Giovanni Manghi about 10 years ago

  • Subject changed from Copy column type to copy string attribute into another one changes the length of the terget column
  • Priority changed from Normal to Severe/Regression
  • Operating System deleted (windows)
  • OS version deleted (7)
  • Affected QGIS version changed from 2.4.0 to master

I'll tag this a regression unless this is one more strange intended behavior, like #11487

I confirm that copying the content of a string column into another string column will "stretch" the second one to accommodate the content of the first one.

Right after doing the operation, in "vector properties > fields" will show the supposed lenght of the second column, but if you remove and re-add the shapefile then a different length will show, the one of the first column!

Creating the second column directly in the field calculator, or adding one empty before hand does not make any difference.

QGIS 1.8 worked as expected (again, if this new behavior is not considered intended).

#2 Updated by Jürgen Fischer about 10 years ago

  • Subject changed from copy string attribute into another one changes the length of the terget column to copy string attribute into another one changes the length of the target column

#3 Updated by aperi2007 - about 10 years ago

I dont understand well.

this bug is also in qgis 2.4 and 2.2 ?

Just to understand if is a blocking issue.
AFAIK the blocker are only the bugs that are not on qgis 2.4

A.

#4 Updated by Giovanni Manghi about 10 years ago

aperi2007 - wrote:

I dont understand well.

this bug is also in qgis 2.4 and 2.2 ?

Just to understand if is a blocking issue.
AFAIK the blocker are only the bugs that are not on qgis 2.4

A.

Until qgis 1.8 this was not an issue, then I tested that any 2.* release is affected.

#5 Updated by aperi2007 - about 10 years ago

SO this could not be consider a blocker issue.

All the user of qgis 2.2 or qgis 2.4 just now live with this feature.

A.

#6 Updated by aperi2007 - about 10 years ago

oops , I wrong to writ.
Dont feature, but issue.

rewrite:

SO this could not be consider a blocker issue.

All the user of qgis 2.2 or qgis 2.4 just now live with this issue.

A.

#7 Updated by Giovanni Manghi about 10 years ago

aperi2007 - wrote:

oops , I wrong to writ.
Dont feature, but issue.

rewrite:

SO this could not be consider a blocker issue.

All the user of qgis 2.2 or qgis 2.4 just now live with this issue.

A.

I have to report all regression as blockers, then if one of the devs wants to downgrade it is his decision.

#8 Updated by Alessandro Pasotti about 10 years ago

Confirmed.

This bug report lacks a fundamental information: the expected behaviour.

I'm not sure about what it should be:

1. abort the operation, failing to create the column with an error message that the data will not fit into the newly created field
2. create the column, automatically expanding the width to contain the longest string and issue a warning
3. create the column truncating the strings and issue a warning
4. actual behaviour (like 3 but without warning, I guess)

I would really prefer n. 2, in that case, this bug report would be only about a missing warning message.

BTW I don't really see this as a blocker, it seems more like a feature than a bug to me.

#9 Updated by Giovanni Manghi about 10 years ago

This bug report lacks a fundamental information: the expected behaviour.

:)

I'm not sure about what it should be:

1. abort the operation, failing to create the column with an error message that the data will not fit into the newly created field
2. create the column, automatically expanding the width to contain the longest string and issue a warning
3. create the column truncating the strings and issue a warning
4. actual behaviour (like 3 but without warning, I guess)

I would really prefer n. 2, in that case, this bug report would be only about a missing warning message.

2 would be good, but as an option. There are good reason a user wants a column to be and remain of a certain length.

BTW I don't really see this as a blocker, it seems more like a feature than a bug to me.

as I said blockers are regression, unless of course is a known/documented change of behavior. This is not the case. This is new, undocumented and certainly something not expected as any other gis packages does not do that (that I'm aware of, of course).

Said that then the common sense must be used, a regression could be perfectly not harmful with no need to fix it in a hurry before a release.

#10 Updated by Martin Dobias about 10 years ago

  • Priority changed from Severe/Regression to Normal

Obviously this is a new feature in OGR's Shapefile driver - from http://www.gdal.org/drv_shapefile.html

"Starting with GDAL/OGR 1.10, the driver knows to auto-extend string and integer fields (up to the 255 bytes limit imposed by the DBF format) to dynamically accomodate for the length of the data to be inserted."

Is this a bug in the end? :-)

Please feel free to close - for the meanwhile I'm lowering the priority.

#11 Updated by Giovanni Manghi about 10 years ago

  • Category changed from Attribute table to Documentation and Help
  • Tracker changed from Bug report to Feature request

Martin Dobias wrote:

Obviously this is a new feature in OGR's Shapefile driver - from http://www.gdal.org/drv_shapefile.html

it os obvious now that we know it :)

Is this a bug in the end? :-)

of course no, but this must be documented in qgis because I feel that users will be puzzled by this change and most of them will not go look in underlying libraries docs.

The description in ogr notes seems ok

"Starting with GDAL/OGR 1.10, the driver knows to auto-extend string and integer fields (up to the 255 bytes limit imposed by the DBF format) to dynamically accomodate for the length of the data to be inserted."

#12 Updated by Alexander Bruy over 9 years ago

  • Status changed from Open to Closed

Also available in: Atom PDF