You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note about data types and strings: for geopackage/sqlite the change in the string length is just different value in the metatable, but the actually it both stored same way. Since in reality it is same data type, this metatable difference is ignored by geodiff.
On the contrary, if the type changes to int from string, the difference should be caught by geodiff
It would be good if this particular case the geodiff can change the metadata entry:
If this value is set to a non-zero value, then certain QGIS operations fail such as when the layer is exported. So we now have a situation where, when using Mergin, certain QGIS operations fail due to this not syncing properly
The text was updated successfully, but these errors were encountered:
Thank you, @PeterPetrik
For now, I have manually replaced the geopackage file in Mergin (delete it and re-upload) and thus forced a "sync" of the metatable and our immediate problem is resolved. I look forward to a fix that will prevent this situation re-occurring.
Note about data types and strings: for geopackage/sqlite the change in the string length is just different value in the metatable, but the actually it both stored same way. Since in reality it is same data type, this metatable difference is ignored by geodiff.
On the contrary, if the type changes to int from string, the difference should be caught by geodiff
It would be good if this particular case the geodiff can change the metadata entry:
If this value is set to a non-zero value, then certain QGIS operations fail such as when the layer is exported. So we now have a situation where, when using Mergin, certain QGIS operations fail due to this not syncing properly
The text was updated successfully, but these errors were encountered: