Hi,
Normally, when you download a form and you already have a form with the
same ID, it gets overwritten.
However, sometimes it is not, and both versions of the form are kept.
What is exactly the condition that determines whether a form is
overwritten or kept? What is the moment where this decision is taken? Is
the relevant id of the new form the one contained within the form, or
the one shown in the formList? (ok they should be the same but I'd like
to know).
All this is because I'm trying to customize ODK Collect so that, just
after sending instances, it re-downloads the forms corresponding to the
uploaded instances. I've already managed to do this in the following
way: after uploading the instances, it builds a hashmap with the formIDs
of the uploaded instances; when you hit OK, instead of finishing, it
calls the FormDownloadList activity, with an extra parameter indicating
the desired formIDs. This parameter is passed to the formList URL, so
the server only responds with the desired formIDs in the list. Then you
have to manually select this/these form/s and they are downloaded.
Everything works, except that SOMETIMES after downloading the new form,
the old one with the same ID is kept.
This (seemingly) never happens when I do everything manually with the
unmodified ODK Collect. So I'm guessing that maybe the deletion of the
old form is not done in the form download task but somewhere else in the
code that I am not calling...........
Any idea?
Thanks
m.
Normally, when you download a form and you already have a form with the
same ID, it gets overwritten.
However, sometimes it is not, and both versions of the form are kept.
I've deleted the folders ".cache" and "metadata" inside the odk folder,
and now it seems this has stopped happening.
In the past I had had forms with the same names but different IDs than
the current ones (though I had already deleted them in Collect). Is it
possible that this was causing the issue?
thanks
m.
···
On 10/09/2011 03:27 PM, Matteo Sisti Sette wrote:
matteo,
it's been a while since i looked at that code, but when you are
downloading forms, we check uniqueness using a combination of the md5
hash of the file and the form id. i don't know exactly how you've
structured your code, but the code you need is in download form task.
there is also code in disk sync task that might be relevant.
.cache is where we store the new forms after we process them the first
time -- makes form loading faster.
metadata is where we store the sqlite db that describes all the forms
and instances.
my guess is that there was some corruption in your db.
yaw
···
On Sun, Oct 9, 2011 at 08:13, Matteo Sisti Sette wrote:
> On 10/09/2011 03:27 PM, Matteo Sisti Sette wrote:
>
>> Normally, when you download a form and you already have a form with the
>> same ID, it gets overwritten.
>> However, sometimes it is not, and both versions of the form are kept.
>
>
> I've deleted the folders ".cache" and "metadata" inside the odk folder, and
> now it seems this has stopped happening.
>
> In the past I had had forms with the same names but different IDs than the
> current ones (though I had already deleted them in Collect). Is it possible
> that this was causing the issue?
>
> thanks
> m.
>
it's been a while since i looked at that code, but when you are
downloading forms, we check uniqueness using a combination of the md5
hash of the file and the form id.
Do you mean that a form with the same ID is not supposed to be
overwritten if the form is not identical?? Or did you mean the md5 hash
of the file name?
thanks
m.
···
On 10/10/2011 04:55 AM, Yaw Anokwa wrote:
The current behavior is supposed to be that if the MD5 of the form file is
not the same, a new entry is added to the form list. If the MD5 is the
same, the newly downloaded form is discarded.
The reason we did this is because you can theoretically 'update' a form
(that is, add/remove questions) and keep the same formid, but the new form
is incompatible with your currently saved instances. Given this, we decided
it was better to make it explicit that the form was not the same and that
the user would have to manually remove one or the other. In general, our
goal is to try to make it hard to break things unless the user explicitly
knows what just changed.
It's a straightforward change to make it so the form is updated (the old
file is removed) if you'd like to customize your own version. We've been
thinking over better ways of managing form updates/changes by using some
type of versioning, but that functionality is planned for some future
version.
···
On Mon, Oct 10, 2011 at 3:03 AM, Matteo Sisti Sette < matteosistisette@gmail.com> wrote:
On 10/10/2011 04:55 AM, Yaw Anokwa wrote:
it's been a while since i looked at that code, but when you are
downloading forms, we check uniqueness using a combination of the md5
hash of the file and the form id.
Do you mean that a form with the same ID is not supposed to be overwritten
if the form is not identical?? Or did you mean the md5 hash of the file
name?
thanks
m.