I have a project set up with some read-only vector layers placed to show in the background, as a reference for the field editors.
Those layers, although they are set as read-only, are not edited or modified by any user, but despite this, whenever I synchronize from QGIS, it asks me to reload those layers from the cloud, as if they had been modified by some editor.
Is there a way to configure those vector layers so that they stay locked and don’t try to download every time I sync the project from the cloud to QGIS?
Thanks.
Imported from GitHub discussion by @kiri03 on 2023-04-16T10:35:55Z
Hey kiri03,
I dont know an answer to your problem, but im curious, where you can set up the layer. Have you done it in the cloud or in QGIS?
Sorry for not helping :o
Imported from GitHub comment by @UlfEichelquetscher on 2023-04-16T14:05:32Z
Hello kiri03,
We have the same problem, when we try to sync from cloud. We identify that every time that upload or sync from device Qfiled Cloud create a new file GPKG despite that layers in the GPKG are not edited or edited by any user.
We have tried all. We have created field UUID´s, . When we try to sync in Qgis the plugin download a new read-only file everey time. We need urgent help, if someone know how to fix that… I appreciate your help
Imported from GitHub comment by @gisDS on 2023-04-21T22:41:28Z
This is likely due to how QGIS save GPKG files. Every time you open a project and close it the GPKG files are updated whether or not there are any changes. I just manually uncheck the files every time when I don’t make any changes to keep from having multiple versions on the cloud.
Imported from GitHub comment by @wanderingnature on 2023-04-26T01:16:19Z
Bumping this still; this feels like a must-have.
We have a very large read-only geopackage for the same reasons. Having to re-upload it every time not only takes a very long time from our users (which then sometimes ends up with a failed upload), but it also requires more storage space on the cloud, which means we need to pay more for it.
As a stop gap solution, I’ve limited the number of historical copies to 1, which retains the project at a reasonable size, but we then of course have no historical data.
I’d expect some kind of option in the “Action” for Individual Layer Settings to set a file-based layer to “read-only” or “copy” (only download from the cloud once, do not repackage or upload when sync’ing back).
Imported from GitHub comment by @idantene on 2024-03-26T08:01:52Z
idantene , what is the action associated to your read-only geopackage in the project properties QField panel’s QFieldCloud section?
Imported from GitHub comment by @nirvn on 2024-03-26T08:05:47Z
It is set to Offline editing. In the Cable Export section, it is set to Copy.
To be honest, I find the documentation regarding the actions (QFieldCloud, Cable Export, and the layer actions) to be lacking.
It would be great to improve on that.
Would you be able to elaborate on the options and differences between e.g. Cable Export and QFieldCloud sections, as well as the available options? I could only find this, but it did not explain the nuances between QFieldCloud and Cable Export, for example.
Imported from GitHub comment by @idantene on 2024-03-26T08:14:25Z
idantene , that’s your problem right there. If you set the layer to offline editing, it will be offlined’ed into data.gpkg, and subsequently restored. Use ‘directly access data source’.
As for the cable export panel, you can ignore, it is of no consequence to cloud project handling.
Imported from GitHub comment by @nirvn on 2024-03-26T08:17:01Z
Thanks nirvn! I’ll give it a go now.
Can you provide a brief explanation about how these options actually work from the cloud packaging point of view?
Imported from GitHub comment by @idantene on 2024-03-26T08:18:13Z
Quick follow-up nirvn, I still occasionally get failed Delta Apply in QFieldCloud, and when I look at the logs, I see the following in the last step (Upload project) (layer names redacted):
08:31:12.432 root INFO Getting project files list…
08:31:14.725 root INFO Local files list for project UUID:
Name Size MD5 Checksum
-------------------------------------------- --------- --------------------------------
my_project.qgs 267706 1b010acc522afa833e444a0ae594da63
my_project_attachments.zip 2110 1a62b963f358f6027314480a908ebd89
options.csv 66 1a4c2f4dc5e149b8b472401e39bc24bc
field_data.gpkg 106496 ac1fd2806ac75d45f4c6ad285896baa1
fixed_layer.gpkg 930824192 cb3ef1c17ba313f71d7ae0893d4df2d7
raster1.tif 81462946 4d7d0d6ed63fff6724691b080876220a
raster2.tif 108372107 d3b8c67a02d9f5f054e2b1433b92d4ec
08:31:14.726 root INFO Uploading project files…
08:31:17.206 /usr/local/lib/python3.10/dist-packages/qfieldcloud_sdk/sdk.py INFO Uploading file "fixed_layer.gpkg"…
Even though fixed_layer.gpkg is now set to Directly access data source, and the only change actually happens in field_data.gpkg. On a succesfull Delta Apply job, I also see it uploads the rasters.
This could be just a wording issue at this point, but it looks weird and does not provide any additional information why the Delta Apply failed..?
EDIT: Adding more information.
I compared the MD5 checksums for the Download Project Directory and Upload Project steps, on both the successful and failed jobs. I noticed two things:
- First, the raster layers have the exact same MD5 checksum, yet they’re still uploaded. This suggests then the remote file’s
name attribute is incorrect or does not match the local file’s name?
- Secondly, the
fixed_layer.gpkg does have a different checksum, though their file size is identical and of course the layer has not gone through any changes.
I’d imagine the delta fails due to the 10min processing limit, but it seems like these files should not be uploaded. I could make a ticket from this, if needed?
Imported from GitHub comment by @idantene on 2024-03-26T09:11:33Z
Hey, kiri03 and idantene , sorry for the late reply, I just found this issue. The problem you described should no longer be the case for a few weeks on app.qfield.cloud. I am closing the issue.
Imported from GitHub comment by @suricactus on 2024-06-19T19:52:48Z
