Bug report #16425
Updated by Jürgen Fischer almost 7 years ago
see comment #16425-3 comment: https://issues.qgis.org/issues/16425#note-3
------
After creating a new layer with processing, integer 64 bits fields (qlonglong) are incorrectly converted.
QGIS version: 2.14 and 2.18 for Windows 7 32 and 64 bits. (I does not fail in Linux nor OSX).
Steps to reproduce:
Load a layer(A) with two fields ID (type integer 64 bits, qlonglong) and geom (type linestring, for example). The ID field values use 18 digits.
Make some geoprocessing with the layer. In our case we ran “Line intersection” algorithm over the layer with itself. The unique field is set to be the ID field.
The resulting layer(B) sets the ID field to be of type text (QGIS 2.18) or uses type real (QGIS 2.14). Now we are not able to too compare the the IDs from A with IDs from B directly. Now:
In 2.18, we are forced to to convert A.ID to string to compare it with B.ID in 2.18, which is the layer that introduced the “error”. As a different workaround, if we try to convert the B.ID (which is int64) to int, we either get it shortened or an error saying it cannot be converted to int (as expected, we miss the to_int64 function).
In 2.14, we cannot make the comparison because the real field cuts off the last digits (it uses scientific notation, see attached image).
Therefore, we think that the qlonglong type should be used in the resulting layer B. While that is not possible, we also miss a to_int64 function to make the first workaround possible.
------
After creating a new layer with processing, integer 64 bits fields (qlonglong) are incorrectly converted.
QGIS version: 2.14 and 2.18 for Windows 7 32 and 64 bits. (I does not fail in Linux nor OSX).
Steps to reproduce:
Load a layer(A) with two fields ID (type integer 64 bits, qlonglong) and geom (type linestring, for example). The ID field values use 18 digits.
Make some geoprocessing with the layer. In our case we ran “Line intersection” algorithm over the layer with itself. The unique field is set to be the ID field.
The resulting layer(B) sets the ID field to be of type text (QGIS 2.18) or uses type real (QGIS 2.14). Now we are not able to too compare the the IDs from A with IDs from B directly. Now:
In 2.18, we are forced to to convert A.ID to string to compare it with B.ID in 2.18, which is the layer that introduced the “error”. As a different workaround, if we try to convert the B.ID (which is int64) to int, we either get it shortened or an error saying it cannot be converted to int (as expected, we miss the to_int64 function).
In 2.14, we cannot make the comparison because the real field cuts off the last digits (it uses scientific notation, see attached image).
Therefore, we think that the qlonglong type should be used in the resulting layer B. While that is not possible, we also miss a to_int64 function to make the first workaround possible.