I am reading the documentation and have not found any references to the possibility of deleting a project instead of archiving it.
Is there this possibility? If not, why?
I question, because in future I do not want to have a cumulative of projects without utilities.
At this point, you can only archive a project. Archiving a project sorts the project to the bottom of the project list and adds
(archived) to the end of its name so that it can be recognized as inactive. One benefit of archiving a project is that it allows you to keep the data from a completed data collection effort and to access it whenever you need.
Could you say more about what you would find helpful about being able to delete a project? Is it to free up space on the server or for another reason?
One use case would be to write unit tests to test project_create which could tear down the test projects, so the test server doesn't get swamped with dud projects.
Hello @Matthew_White , forgive me for the delay in replying.
Yes, the storage mostly. But I say of useless project buildup because (what I would do) the project was archived for over 6 months. I export the information for future analysis and remove it from ODK, as it has already been collected and studied. If necessary in the ODK I perform the manual import and continue as needed.
(From my point of view) My ODK has to be is an organic data collection tool and not a Data Lake
By: Google Translate
Hello, how are you? Do you think it makes sense what was said earlier?
Hi @Wellington_Fonseca! Thanks for your post — it's useful to hear your thinking.
One thing I wanted to mention is that project deletion is implemented in the API, so that's a possibility if you want to remove any of your projects. However, we have some concern that if we add project deletion to the frontend, a user may delete a project accidentally and wish to restore it. In general, resource deletion (for projects, forms, submissions, and so on) is something we're still thinking through. We're not planning to add additional support for resource deletion over the next couple of releases, but it's definitely something on our minds.
Also, note that while the API supports project and form deletion, I believe that at this point those actions are soft deletions.
How so? eg you cant subsequently add a project with the same name?
I don't think there's a restriction along those lines for project names. (If you really want to, you can have multiple projects with the same name. Not for the faint of heart!) There is a restriction for forms: you can't upload a form with the same id and version as another form in the project, even if the other form has been deleted. (There's been some discussion elsewhere about how this relates to draft or training forms. Again, more to come around this at some point!) By soft deletion, I just meant that while project deletion will make a project inaccessible to the API, it will still exist in the database (at least as that endpoint is implemented right now).
Forgive me for the delay!
I was engaged in a project and spent time off the web.
I understood the concept, but I think leaving this method of exclusion in the document would be important. Remembering that is the responsibility of the server administrator and not odk.
Because the accumulation of old projects will surely occur over time. And a polluted interface is not cool for a user.
Can I second the need to be able to really delete, and also to track/manage space generally on ODK server?
It would be good if ODK Central was more aware of space and allowed management of projects and forms, including deletion of old forms, but also compaction of current forms. At present, once the server is full of media-rich forms, it is almost impossible to do anything (you can't download, as the ZIP generation also requires space; it would be good if there was an option to extract just form data and not data+media in this case).
Is there any manual way to manage this in meanwhile?... Currently I'm struggling to extract forms from a server maxed out by an ODK Central project with many photographs, which I don't want to delete until they are extracted to our archive...
Are you using DigitalOcean to host Central? If so, note that you have options through DigitalOcean to manage your RAM and disk storage. For example, we recommend the following in the Central documentation:
The size option affects a few things, but the most important is the amount of memory available to your server. Memory does not affect storage space, it sets the amount of "thinking room" the server gets while it's working on things. If you don't expect many forms to be submitted at once and you don't expect many large media attachments, you can start with 1GB. Higher-load servers and servers which handle many image or video attachments may need 2GB or more. It is pretty easy to upgrade to a larger size later.
What do you see when you try downloading the submission data .zip file? Do you see an error message, or is the .zip file empty? Are you encountering another issue in addition to the .zip file download?
You may find this topic helpful, especially @LN's suggestions here. Let us know if you try one or more of those suggestions and whether that helps. (By the way, we'll soon be adding instructions to the Central documentation around the last option, adding swap.)
Down the road, I could see how it would be helpful to add an option to exclude media files from the .zip file, generating just the CSV files. @LN, am I right that Briefcase has an option already along those lines, to exclude media files from the export? Do you think something like that would be useful for Central as well? (CC @issa.)
Thanks for suggestions on this: yes, was on DigitalOcean and so upping RAM and disk unlocked the system a bit (at one point I could not even update ODK Central via terminal), but I still never managed to have a working ZIP download (unclear how much I would have to upgrade to get this working, and finance is not unlimited on this project!).
My problem does sounds very similar to the thread linked on blank ZIPs: I guess the memory needed to generate ZIP download when there are many images (and of high res), is problematic.
Ultimately I had to give up and simply back up the raw submissions from ODK Collect (directly from the collecting devices), but this was not particularly satisfying solution, as I have XMLs instead of CSVs.
Perhaps should have tried Briefcase instead, although now too late as have powered down VM... I had understood from documentation that Briefcase does not yet work with Central.
Thanks all for your efforts on Central.
In general, if there are many high-res images, that will tend to require more memory. However, as part of the upcoming Central v0.7 release (likely coming out this week), we've also made some changes that should help in this case:
- We've made some improvements to how .zip files are generated, reducing how much memory is required in some cases.
- We've documented how to add swap to a DigitalOcean droplet. Adding swap should make it easier to export a .zip file with many attachments while on a 1GB or 2GB droplet.
The most recent version of Central supports Briefcase, though it might not have when you first installed Central. That said, we do want Central users to be able to download their data without having to use Briefcase. If you end up trying the upcoming v0.7 release (or later) for a project with many media files, it'd be great to hear whether you're able to download a .zip file successfully.