Dear Chris, ODK Developers,
I have to exploit the ODK Aggregate feature that allows some metadata in a
form to change and the form to be still uploadable. In particular, I
changed all constraints in a form from true to false and proceeded to
upload this form. However, the form couldn't be uploaded as Aggregate
complains of a duplicate form existing.
I am already using Aggregate v1.2, and on the form, changed nothing else
apart from the constraints. Even the form id remained constant.
What should I do to have Aggregate accept the new form with the changes?
Kihara Absolomon :: Software Developer :: Movert Technologies :: +254 733
567 797 :: http://soloincc.movert.co.ke/
···
-----------------------------------------------------------------------------------------------------------------------------------------------
"Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning." – Rick Cook
Hi Kihara,
Did you update the version number? From the release notes:
Whenever a form or any of its media files are modified, the version
attribute in the top-level element (where the form id is defined) must be
changed. Version attributes are recommended to be of the form "yyyymmddnn",
e.g., 2012060400 -- the last two digits are the form iteration within the
given day. They must be integer values and the new value must compare
lexically greater than the prior value (this means, for example, since "9"
compares lexically greater than "10", you cannot update a version from 9 to
10 -- but you could upgrade from "09" to "10").
If you did and you still get an error, can you post the exact error text? I
thought that we'd tested the constraints-changing case pretty well.
As a last resort, you can get to the bottom of the problem by going back to
your original form and then just changing one thing at a time. Actually,
you can start with no changes: if you re-upload what you think is the
original form, does Aggregate accept it? (It accepts unchanged forms.)
Then, change one constraint. Does that work? And so on. That way, you can
pin-point the change that's tripping it up.
Best,
Chris
···
On Tuesday, October 30, 2012, Kihara Absolomon wrote:
Dear Chris, ODK Developers,
I have to exploit the ODK Aggregate feature that allows some metadata in a
form to change and the form to be still uploadable. In particular, I
changed all constraints in a form from true to false and proceeded to
upload this form. However, the form couldn't be uploaded as Aggregate
complains of a duplicate form existing.
I am already using Aggregate v1.2, and on the form, changed nothing else
apart from the constraints. Even the form id remained constant.
What should I do to have Aggregate accept the new form with the changes?
Kihara Absolomon :: Software Developer :: Movert Technologies :: +254 733
567 797 :: http://soloincc.movert.co.ke/
"Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning." – Rick Cook
Hi Chris,
Thanks a lot for that pointer, it worked, at least to the point of
replacing the older version. I was a bit sceptical at first as the older
version did not have the version attribute specified, but all went ok. But
I am afraid thats where the good news end.
On uploading the new version, I have noticed that you are adding a comment
of when the form was uploaded and from which url. Something like "". My form has a GNU licence from the
second line, which goes all the way to the 22nd line. The comment Aggregate
adds is added within my GNU licence which is a comment resulting to
something like:
Copyright 2012 ILRI
This is a standalone XForm to be used with ODK.
This is a free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This XForm is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this XForm. If not, see <http://www.gnu.org/licenses/>.
-->
Assuming the uploaded form(Above snippet) has id='usda_goats_v3' and
version='2012103001'
- When trying to upload a newer version of the form (id='usda_goats_v3'
and version='2012103002'), the upload fails! The only change is the removal
of the license snippet.
- When I change the ID only (id='usda_goats_v5' and
version='2012103002') of the form, the upload to Aggregate succeeds.
- When I use the same id and version (id='usda_goats_v3' and
version='2012103001') on a new form (no change whatsoever), the upload
fails.
- On ODK Collect on the phone, when I tried downloading the uploaded
version(id='usda_goats_v3' and version='2012103001') the download fails!
- On ODK Collect, I am able to download a form with a new id
(id='usda_goats_v5' and version='2012103002').
Might the comment which is being added by Aggregate cause all this chaos?
Thanks
Kihara
···
On Tue, Oct 30, 2012 at 3:30 PM, Christopher Robert wrote:
Hi Kihara,
Did you update the version number? From the release notes:
Whenever a form or any of its media files are modified, the version
attribute in the top-level element (where the form id is defined) must be
changed. Version attributes are recommended to be of the form "yyyymmddnn",
e.g., 2012060400 -- the last two digits are the form iteration within the
given day. They must be integer values and the new value must compare
lexically greater than the prior value (this means, for example, since "9"
compares lexically greater than "10", you cannot update a version from 9 to
10 -- but you could upgrade from "09" to "10").
If you did and you still get an error, can you post the exact error text?
I thought that we'd tested the constraints-changing case pretty well.
As a last resort, you can get to the bottom of the problem by going back
to your original form and then just changing one thing at a time. Actually,
you can start with no changes: if you re-upload what you think is the
original form, does Aggregate accept it? (It accepts unchanged forms.)
Then, change one constraint. Does that work? And so on. That way, you can
pin-point the change that's tripping it up.
Best,
Chris
On Tuesday, October 30, 2012, Kihara Absolomon wrote:
Dear Chris, ODK Developers,
I have to exploit the ODK Aggregate feature that allows some metadata in
a form to change and the form to be still uploadable. In particular, I
changed all constraints in a form from true to false and proceeded to
upload this form. However, the form couldn't be uploaded as Aggregate
complains of a duplicate form existing.
I am already using Aggregate v1.2, and on the form, changed nothing else
apart from the constraints. Even the form id remained constant.
What should I do to have Aggregate accept the new form with the changes?
Kihara Absolomon :: Software Developer :: Movert Technologies :: +254
733 567 797 :: http://soloincc.movert.co.ke/
"Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning." – Rick Cook
The comment-insertion logic searches for the first '>' character in the
file, and inserts the load timestamp comment in that location.
The code doesn't expect or handle comments, so it ends up inserting the
comment within the comment, which messes a bunch of things up.
Unfortunately, in this instance, I think the only fix is to delete the form
entirely, then upload the revised form. Note that form deletion can take a
while if you have many form submissions (it has to delete all the
submissions individually before the form can be removed).
Do you have submission data that you need to preserve on this server? If
so, let me know, as you will require a hacked version of ODK Briefcase to
access it before deleting the form.
This is all because the inserted comment prevents XML parsing to succeed on
the altered form, causing all sorts of things to break.
Going forward, as long as your licensing comment does not itself contain a
'>' character, you should be able to retain the licensing comment
at the front of your file. I've created this issue for the erroneous
timestamp comment insertion logic:
http://code.google.com/p/opendatakit/issues/detail?id=716
Mitch
···
On Tue, Oct 30, 2012 at 7:29 AM, Christopher Robert wrote:
Hi Kihara,
This sounds complicated!
There was an issue with these comments in one of the Aggregate and/or
Collect versions. Mitch should be online soon so maybe he can enlighten..?
Chris
P.S. Again, though, the exact error messages might be helpful when you say
that things fail. The uploads give specific error messages, and the form
download on Collect as well. Mitch (or I) might be able to give a better
answer if presented with the exact errors.
On Tuesday, October 30, 2012, Kihara Absolomon wrote:
Hi Chris,
Thanks a lot for that pointer, it worked, at least to the point of
replacing the older version. I was a bit sceptical at first as the older
version did not have the version attribute specified, but all went ok. But
I am afraid thats where the good news end.
On uploading the new version, I have noticed that you are adding a
comment of when the form was uploaded and from which url. Something like "
". My form has a GNU licence from
the second line, which goes all the way to the 22nd line. The comment
Aggregate adds is added within my GNU licence which is a comment resulting
to something like:
Copyright 2012 ILRI
This is a standalone XForm to be used with ODK.
This is a free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This XForm is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this XForm. If not, see http://www.gnu.org/licenses/.
-->
Assuming the uploaded form(Above snippet) has id='usda_goats_v3' and
version='2012103001'
- When trying to upload a newer version of the form
(id='usda_goats_v3' and version='2012103002'), the upload fails! The
only change is the removal of the license snippet.
- When I change the ID only (id='usda_goats_v5' and version='
2012103002') of the form, the upload to Aggregate succeeds.
- When I use the same id and version (id='usda_goats_v3' and version='
2012103001') on a new form (no change whatsoever), the upload fails.
- On ODK Collect on the phone, when I tried downloading the uploaded
version(id='usda_goats_v3' and version='2012103001') the download
fails!
- On ODK Collect, I am able to download a form with a new id
(id='usda_goats_v5' and version='2012103002').
Might the comment which is being added by Aggregate cause all this chaos?
Thanks
Kihara
On Tue, Oct 30, 2012 at 3:30 PM, Christopher Robert < chrislrobert@gmail.com> wrote:
Hi Kihara,
Did you update the version number? From the release notes:
Whenever a form or any of its media files are modified, the version
attribute in the top-level element (where the form id is defined) must be
changed. Version attributes are recommended to be of the form "yyyymmddnn",
e.g., 2012060400 -- the last two digits are the form iteration within
the given day. They must be integer values and the new value must compare
lexically greater than the prior value (this means, for example, since "9"
compares lexically greater than "10", you cannot update a version from 9 to
10 -- but you could upgrade from "09" to "10").
If you did and you still get an error, can you post the exact error
text? I thought that we'd tested the constraints-changing case pretty well.
As a last resort, you can get to the bottom of the problem by going back
to your original form and then just changing one thing at a time. Actually,
you can start with no changes: if you re-upload what you think is the
original form, does Aggregate accept it? (It accepts unchanged forms.)
Then, change one constraint. Does that work? And so on. That way, you can
pin-point the change that's tripping it up.
Best,
Chris
On Tuesday, October 30, 2012, Kihara Absolomon wrote:
Dear Chris, ODK Developers,
I have to exploit the ODK Aggregate feature that allows some metadata
in a form to change and the form to be still uploadable. In particular, I
changed all constraints in a form from true to false and proceeded to
upload this form. However, the form couldn't be uploaded as Aggregate
complains of a duplicate form existing.
I am already using Aggregate v1.2, and on the form, changed nothing
else apart from the constraints. Even the form id remained constant.
What should I do to have Aggregate accept the new form with the changes?
Kihara Absolomon :: Software Developer :: Movert Technologies :: +254
733 567 797 :: http://soloincc.movert.co.ke/
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning." – Rick
Cook
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
Note that there may be parsing problems in ODK Collect with a comment as
the first element of the file.
You may need to place the comment within the element to get ODK
Collect to properly detect the form.
ODK Aggregate was trying to insert its comment after the first element
within the element, so if you have
...
It was attempting to insert the load timestamp comment immediately after
the tag.
···
On Tue, Oct 30, 2012 at 8:40 AM, Mitch S wrote:
The comment-insertion logic searches for the first '>' character in the
file, and inserts the load timestamp comment in that location.
The code doesn't expect or handle comments, so it ends up inserting the
comment within the comment, which messes a bunch of things up.
Unfortunately, in this instance, I think the only fix is to delete the
form entirely, then upload the revised form. Note that form deletion can
take a while if you have many form submissions (it has to delete all the
submissions individually before the form can be removed).
Do you have submission data that you need to preserve on this server? If
so, let me know, as you will require a hacked version of ODK Briefcase to
access it before deleting the form.
This is all because the inserted comment prevents XML parsing to succeed
on the altered form, causing all sorts of things to break.
Going forward, as long as your licensing comment does not itself contain a
'>' character, you should be able to retain the licensing comment
at the front of your file. I've created this issue for the erroneous
timestamp comment insertion logic:
http://code.google.com/p/opendatakit/issues/detail?id=716
Mitch
On Tue, Oct 30, 2012 at 7:29 AM, Christopher Robert < chrislrobert@gmail.com> wrote:
Hi Kihara,
This sounds complicated!
There was an issue with these comments in one of the Aggregate and/or
Collect versions. Mitch should be online soon so maybe he can enlighten..?
Chris
P.S. Again, though, the exact error messages might be helpful when you
say that things fail. The uploads give specific error messages, and the
form download on Collect as well. Mitch (or I) might be able to give a
better answer if presented with the exact errors.
On Tuesday, October 30, 2012, Kihara Absolomon wrote:
Hi Chris,
Thanks a lot for that pointer, it worked, at least to the point of
replacing the older version. I was a bit sceptical at first as the older
version did not have the version attribute specified, but all went ok. But
I am afraid thats where the good news end.
On uploading the new version, I have noticed that you are adding a
comment of when the form was uploaded and from which url. Something like "
". My form has a GNU licence from
the second line, which goes all the way to the 22nd line. The comment
Aggregate adds is added within my GNU licence which is a comment resulting
to something like:
Copyright 2012 ILRI
This is a standalone XForm to be used with ODK.
This is a free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This XForm is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this XForm. If not, see http://www.gnu.org/licenses/.
-->
Assuming the uploaded form(Above snippet) has id='usda_goats_v3' and
version='2012103001'
- When trying to upload a newer version of the form
(id='usda_goats_v3' and version='2012103002'), the upload fails! The
only change is the removal of the license snippet.
- When I change the ID only (id='usda_goats_v5' and version='
2012103002') of the form, the upload to Aggregate succeeds.
- When I use the same id and version (id='usda_goats_v3' and
version='2012103001') on a new form (no change whatsoever), the
upload fails.
- On ODK Collect on the phone, when I tried downloading the uploaded
version(id='usda_goats_v3' and version='2012103001') the download
fails!
- On ODK Collect, I am able to download a form with a new id
(id='usda_goats_v5' and version='2012103002').
Might the comment which is being added by Aggregate cause all this chaos?
Thanks
Kihara
On Tue, Oct 30, 2012 at 3:30 PM, Christopher Robert < chrislrobert@gmail.com> wrote:
Hi Kihara,
Did you update the version number? From the release notes:
Whenever a form or any of its media files are modified, the version
attribute in the top-level element (where the form id is defined) must be
changed. Version attributes are recommended to be of the form "yyyymmddnn",
e.g., 2012060400 -- the last two digits are the form iteration within
the given day. They must be integer values and the new value must compare
lexically greater than the prior value (this means, for example, since "9"
compares lexically greater than "10", you cannot update a version from 9 to
10 -- but you could upgrade from "09" to "10").
If you did and you still get an error, can you post the exact error
text? I thought that we'd tested the constraints-changing case pretty well.
As a last resort, you can get to the bottom of the problem by going
back to your original form and then just changing one thing at a time.
Actually, you can start with no changes: if you re-upload what you think is
the original form, does Aggregate accept it? (It accepts unchanged forms.)
Then, change one constraint. Does that work? And so on. That way, you can
pin-point the change that's tripping it up.
Best,
Chris
On Tuesday, October 30, 2012, Kihara Absolomon wrote:
Dear Chris, ODK Developers,
I have to exploit the ODK Aggregate feature that allows some metadata
in a form to change and the form to be still uploadable. In particular, I
changed all constraints in a form from true to false and proceeded to
upload this form. However, the form couldn't be uploaded as Aggregate
complains of a duplicate form existing.
I am already using Aggregate v1.2, and on the form, changed nothing
else apart from the constraints. Even the form id remained constant.
What should I do to have Aggregate accept the new form with the
changes?
Kihara Absolomon :: Software Developer :: Movert Technologies :: +254
733 567 797 :: http://soloincc.movert.co.ke/
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning." – Rick
Cook
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
Hi Kihara,
This sounds complicated!
There was an issue with these comments in one of the Aggregate and/or
Collect versions. Mitch should be online soon so maybe he can enlighten..?
Chris
P.S. Again, though, the exact error messages might be helpful when you say
that things fail. The uploads give specific error messages, and the form
download on Collect as well. Mitch (or I) might be able to give a better
answer if presented with the exact errors.
···
On Tuesday, October 30, 2012, Kihara Absolomon wrote:
Hi Chris,
Thanks a lot for that pointer, it worked, at least to the point of
replacing the older version. I was a bit sceptical at first as the older
version did not have the version attribute specified, but all went ok. But
I am afraid thats where the good news end.
On uploading the new version, I have noticed that you are adding a comment
of when the form was uploaded and from which url. Something like "". My form has a GNU licence from the
second line, which goes all the way to the 22nd line. The comment Aggregate
adds is added within my GNU licence which is a comment resulting to
something like:
Copyright 2012 ILRI
This is a standalone XForm to be used with ODK.
This is a free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This XForm is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this XForm. If not, see http://www.gnu.org/licenses/.
-->
Assuming the uploaded form(Above snippet) has id='usda_goats_v3' and
version='2012103001'
- When trying to upload a newer version of the form
(id='usda_goats_v3' and version='2012103002'), the upload fails! The only
change is the removal of the license snippet.
- When I change the ID only (id='usda_goats_v5' and
version='2012103002') of the form, the upload to Aggregate succeeds.
- When I use the same id and version (id='usda_goats_v3' and
version='2012103001') on a new form (no change whatsoever), the upload
fails.
- On ODK Collect on the phone, when I tried downloading the uploaded
version(id='usda_goats_v3' and version='2012103001') the download fails!
- On ODK Collect, I am able to download a form with a new id
(id='usda_goats_v5' and version='2012103002').
Might the comment which is being added by Aggregate cause all this chaos?
Thanks
Kihara
On Tue, Oct 30, 2012 at 3:30 PM, Christopher Robert < chrislrobert@gmail.com <javascript:_e({}, 'cvml', 'chrislrobert@gmail.com');>> wrote:
Hi Kihara,
Did you update the version number? From the release notes:
Whenever a form or any of its media files are modified, the version
attribute in the top-level element (where the form id is defined) must be
changed. Version attributes are recommended to be of the form "yyyymmddnn",
e.g., 2012060400 -- the last two digits are the form iteration within
the given day. They must be integer values and the new value must compare
lexically greater than the prior value (this means, for example, since "9"
compares lexically greater than "10", you cannot update a version from 9 to
10 -- but you could upgrade from "09" to "10").
If you did and you still get an error, can you post the exact error text?
I thought that we'd tested the constraints-changing case pretty well.
As a last resort, you can get to the bottom of the problem by going back
to your original form and then just changing one thing at a time. Actually,
you can start with no changes: if you re-upload what you think is the
original form, does Aggregate accept it? (It accepts unchanged forms.)
Then, change one constraint. Does that work? And so on. That way, you can
pin-point the change that's tripping it up.
Best,
Chris
On Tuesday, October 30, 2012, Kihara Absolomon wrote:
Dear Chris, ODK Developers,
I have to exploit the ODK Aggregate feature that allows some metadata in
a form to change and the form to be still uploadable. In particular, I
changed all constraints in a form from true to false and proceeded to
upload this form. However, the form couldn't be uploaded as Aggregate
complains of a duplicate form existing.
I am already using Aggregate v1.2, and on the form, changed nothing else
apart from the constraints. Even the form id remained constant.
What should I do to have Aggregate accept the new form with the changes?
Kihara Absolomon :: Software Developer :: Movert Technologies :: +254
733 567 797 :: http://soloincc.movert.co.ke/
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning." – Rick
Cook
Hi Mitch,
That explains a lot. I guessed it might be the problem but I wasn't sure. I
do have submission data which I do need to preserver. Deleting the
instances unfortunately is not an option for me! Please send me the hacked
ODK briefcase.
As for the errors which I was getting, I was actually meant to insert them,
I must have hit the send button a tad soon. Below are the error messages:
Assuming the uploaded form(Above snippet) has id='usda_goats_v3' and
version='2012103001'
- When trying to upload a newer version of the form (id='usda_goats_v3'
and version='2012103002'), the upload fails! The only change is the
removal of the license snippet. ==>
···
-
- Oct 30, 2012 6:49:45 PM
org.opendatakit.aggregate.servlet.FormUploadServlet doPost
- WARNING: Form upload parsing error:
org.javarosa.xform.parse.XFormParseException: XML Syntax Error
at Line: 22,
Column: 46!
- Oct 30, 2012 6:49:52 PM org.opendatakit.aggregate.form.FormFactory
internalGetForms
Line 22 on the new form is: <name />
- Line 22 on the old form is: *along with this XForm. If not, see <
http://www.gnu.org/licenses/>.*
- When I change the ID only (id='usda_goats_v5' and version='2012103002')
of the form, the upload to Aggregate succeeds.
- When I use the same id and version (id='usda_goats_v3' and version='
2012103001') on a new form (no change whatsoever), the upload
fails. ==> This
actually works!
- On ODK Collect on the phone, when I tried downloading the uploaded
version(id='usda_goats_v3' and version='2012103001') the download fails!
==> XML Syntax Error at Line: 5 ==> This is where the comment within a
comment starts.
- On ODK Collect, I am able to download a form with a new id
(id='usda_goats_v5' and version='2012103002').
Thanks
Kihara
On Tue, Oct 30, 2012 at 6:40 PM, Mitch S mitchellsundt@gmail.com wrote:
The comment-insertion logic searches for the first '>' character in the
file, and inserts the load timestamp comment in that location.
The code doesn't expect or handle comments, so it ends up inserting the
comment within the comment, which messes a bunch of things up.
Unfortunately, in this instance, I think the only fix is to delete the
form entirely, then upload the revised form. Note that form deletion can
take a while if you have many form submissions (it has to delete all the
submissions individually before the form can be removed).
Do you have submission data that you need to preserve on this server? If
so, let me know, as you will require a hacked version of ODK Briefcase to
access it before deleting the form.
This is all because the inserted comment prevents XML parsing to succeed
on the altered form, causing all sorts of things to break.
Going forward, as long as your licensing comment does not itself contain a
'>' character, you should be able to retain the licensing comment
at the front of your file. I've created this issue for the erroneous
timestamp comment insertion logic:
http://code.google.com/p/opendatakit/issues/detail?id=716
Mitch
On Tue, Oct 30, 2012 at 7:29 AM, Christopher Robert < chrislrobert@gmail.com> wrote:
Hi Kihara,
This sounds complicated!
There was an issue with these comments in one of the Aggregate and/or
Collect versions. Mitch should be online soon so maybe he can enlighten..?
Chris
P.S. Again, though, the exact error messages might be helpful when you
say that things fail. The uploads give specific error messages, and the
form download on Collect as well. Mitch (or I) might be able to give a
better answer if presented with the exact errors.
On Tuesday, October 30, 2012, Kihara Absolomon wrote:
Hi Chris,
Thanks a lot for that pointer, it worked, at least to the point of
replacing the older version. I was a bit sceptical at first as the older
version did not have the version attribute specified, but all went ok. But
I am afraid thats where the good news end.
On uploading the new version, I have noticed that you are adding a
comment of when the form was uploaded and from which url. Something like "
". My form has a GNU licence from
the second line, which goes all the way to the 22nd line. The comment
Aggregate adds is added within my GNU licence which is a comment resulting
to something like:
Copyright 2012 ILRI
This is a standalone XForm to be used with ODK.
This is a free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This XForm is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this XForm. If not, see http://www.gnu.org/licenses/.
-->
Assuming the uploaded form(Above snippet) has id='usda_goats_v3' and
version='2012103001'
- When trying to upload a newer version of the form
(id='usda_goats_v3' and version='2012103002'), the upload fails! The
only change is the removal of the license snippet.
- When I change the ID only (id='usda_goats_v5' and version='
2012103002') of the form, the upload to Aggregate succeeds.
- When I use the same id and version (id='usda_goats_v3' and
version='2012103001') on a new form (no change whatsoever), the
upload fails.
- On ODK Collect on the phone, when I tried downloading the uploaded
version(id='usda_goats_v3' and version='2012103001') the download
fails!
- On ODK Collect, I am able to download a form with a new id
(id='usda_goats_v5' and version='2012103002').
Might the comment which is being added by Aggregate cause all this chaos?
Thanks
Kihara
On Tue, Oct 30, 2012 at 3:30 PM, Christopher Robert < chrislrobert@gmail.com> wrote:
Hi Kihara,
Did you update the version number? From the release notes:
Whenever a form or any of its media files are modified, the version
attribute in the top-level element (where the form id is defined) must be
changed. Version attributes are recommended to be of the form "yyyymmddnn",
e.g., 2012060400 -- the last two digits are the form iteration within
the given day. They must be integer values and the new value must compare
lexically greater than the prior value (this means, for example, since "9"
compares lexically greater than "10", you cannot update a version from 9 to
10 -- but you could upgrade from "09" to "10").
If you did and you still get an error, can you post the exact error
text? I thought that we'd tested the constraints-changing case pretty well.
As a last resort, you can get to the bottom of the problem by going
back to your original form and then just changing one thing at a time.
Actually, you can start with no changes: if you re-upload what you think is
the original form, does Aggregate accept it? (It accepts unchanged forms.)
Then, change one constraint. Does that work? And so on. That way, you can
pin-point the change that's tripping it up.
Best,
Chris
On Tuesday, October 30, 2012, Kihara Absolomon wrote:
Dear Chris, ODK Developers,
I have to exploit the ODK Aggregate feature that allows some metadata
in a form to change and the form to be still uploadable. In particular, I
changed all constraints in a form from true to false and proceeded to
upload this form. However, the form couldn't be uploaded as Aggregate
complains of a duplicate form existing.
I am already using Aggregate v1.2, and on the form, changed nothing
else apart from the constraints. Even the form id remained constant.
What should I do to have Aggregate accept the new form with the
changes?
Kihara Absolomon :: Software Developer :: Movert Technologies :: +254
733 567 797 :: http://soloincc.movert.co.ke/
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning." – Rick
Cook
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
Hi Mitch,
Yes I think that should work. The problem I think is caused when the
already uploaded form is trying to be parsed to compare the changes with
the new form! As you said, deleting the uploaded form might be the solution.
Regards
Kihara
···
On Tue, Oct 30, 2012 at 6:52 PM, Mitch S wrote:
Note that there may be parsing problems in ODK Collect with a comment as
the first element of the file.
You may need to place the comment within the element to get ODK
Collect to properly detect the form.
ODK Aggregate was trying to insert its comment after the first element
within the element, so if you have
...
It was attempting to insert the load timestamp comment immediately after
the tag.
On Tue, Oct 30, 2012 at 8:40 AM, Mitch S mitchellsundt@gmail.com wrote:
The comment-insertion logic searches for the first '>' character in the
file, and inserts the load timestamp comment in that location.
The code doesn't expect or handle comments, so it ends up inserting the
comment within the comment, which messes a bunch of things up.
Unfortunately, in this instance, I think the only fix is to delete the
form entirely, then upload the revised form. Note that form deletion can
take a while if you have many form submissions (it has to delete all the
submissions individually before the form can be removed).
Do you have submission data that you need to preserve on this server? If
so, let me know, as you will require a hacked version of ODK Briefcase to
access it before deleting the form.
This is all because the inserted comment prevents XML parsing to succeed
on the altered form, causing all sorts of things to break.
Going forward, as long as your licensing comment does not itself contain
a '>' character, you should be able to retain the licensing comment
at the front of your file. I've created this issue for the erroneous
timestamp comment insertion logic:
http://code.google.com/p/opendatakit/issues/detail?id=716
Mitch
On Tue, Oct 30, 2012 at 7:29 AM, Christopher Robert < chrislrobert@gmail.com> wrote:
Hi Kihara,
This sounds complicated!
There was an issue with these comments in one of the Aggregate and/or
Collect versions. Mitch should be online soon so maybe he can enlighten..?
Chris
P.S. Again, though, the exact error messages might be helpful when you
say that things fail. The uploads give specific error messages, and the
form download on Collect as well. Mitch (or I) might be able to give a
better answer if presented with the exact errors.
On Tuesday, October 30, 2012, Kihara Absolomon wrote:
Hi Chris,
Thanks a lot for that pointer, it worked, at least to the point of
replacing the older version. I was a bit sceptical at first as the older
version did not have the version attribute specified, but all went ok. But
I am afraid thats where the good news end.
On uploading the new version, I have noticed that you are adding a
comment of when the form was uploaded and from which url. Something like "
". My form has a GNU licence from
the second line, which goes all the way to the 22nd line. The comment
Aggregate adds is added within my GNU licence which is a comment resulting
to something like:
Copyright 2012 ILRI
This is a standalone XForm to be used with ODK.
This is a free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This XForm is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this XForm. If not, see http://www.gnu.org/licenses/.
-->
Assuming the uploaded form(Above snippet) has id='usda_goats_v3' and
version='2012103001'
- When trying to upload a newer version of the form
(id='usda_goats_v3' and version='2012103002'), the upload fails!
The only change is the removal of the license snippet.
- When I change the ID only (id='usda_goats_v5' and version='
2012103002') of the form, the upload to Aggregate succeeds.
- When I use the same id and version (id='usda_goats_v3' and
version='2012103001') on a new form (no change whatsoever), the
upload fails.
- On ODK Collect on the phone, when I tried downloading the
uploaded version(id='usda_goats_v3' and version='2012103001') the
download fails!
- On ODK Collect, I am able to download a form with a new id
(id='usda_goats_v5' and version='2012103002').
Might the comment which is being added by Aggregate cause all this
chaos?
Thanks
Kihara
On Tue, Oct 30, 2012 at 3:30 PM, Christopher Robert < chrislrobert@gmail.com> wrote:
Hi Kihara,
Did you update the version number? From the release notes:
Whenever a form or any of its media files are modified, the version
attribute in the top-level element (where the form id is defined) must be
changed. Version attributes are recommended to be of the form "yyyymmddnn",
e.g., 2012060400 -- the last two digits are the form iteration within
the given day. They must be integer values and the new value must compare
lexically greater than the prior value (this means, for example, since "9"
compares lexically greater than "10", you cannot update a version from 9 to
10 -- but you could upgrade from "09" to "10").
If you did and you still get an error, can you post the exact error
text? I thought that we'd tested the constraints-changing case pretty well.
As a last resort, you can get to the bottom of the problem by going
back to your original form and then just changing one thing at a time.
Actually, you can start with no changes: if you re-upload what you think is
the original form, does Aggregate accept it? (It accepts unchanged forms.)
Then, change one constraint. Does that work? And so on. That way, you can
pin-point the change that's tripping it up.
Best,
Chris
On Tuesday, October 30, 2012, Kihara Absolomon wrote:
Dear Chris, ODK Developers,
I have to exploit the ODK Aggregate feature that allows some metadata
in a form to change and the form to be still uploadable. In particular, I
changed all constraints in a form from true to false and proceeded to
upload this form. However, the form couldn't be uploaded as Aggregate
complains of a duplicate form existing.
I am already using Aggregate v1.2, and on the form, changed nothing
else apart from the constraints. Even the form id remained constant.
What should I do to have Aggregate accept the new form with the
changes?
Kihara Absolomon :: Software Developer :: Movert Technologies :: +254
733 567 797 :: http://soloincc.movert.co.ke/
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning." – Rick
Cook
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
OK. I have uploaded an ODK Briefcase 1.2.1 to the downloads page:
http://code.google.com/p/opendatakit/downloads/list
And added instructions for how to use it to recover data for a corrupted
form on an ODK Aggregate server:
http://code.google.com/p/opendatakit/wiki/ODKBriefcase#Recovering_Data_when_Form_Definition_Corrupted
Let me know if anything does not work.
Mitch
···
On Tue, Oct 30, 2012 at 9:00 AM, Kihara Absolomon wrote:
Hi Mitch,
Yes I think that should work. The problem I think is caused when the
already uploaded form is trying to be parsed to compare the changes with
the new form! As you said, deleting the uploaded form might be the solution.
Regards
Kihara
On Tue, Oct 30, 2012 at 6:52 PM, Mitch S mitchellsundt@gmail.com wrote:
Note that there may be parsing problems in ODK Collect with a comment as
the first element of the file.
You may need to place the comment within the element to get ODK
Collect to properly detect the form.
ODK Aggregate was trying to insert its comment after the first element
within the element, so if you have
...
It was attempting to insert the load timestamp comment immediately after
the tag.
On Tue, Oct 30, 2012 at 8:40 AM, Mitch S mitchellsundt@gmail.com wrote:
The comment-insertion logic searches for the first '>' character in the
file, and inserts the load timestamp comment in that location.
The code doesn't expect or handle comments, so it ends up inserting the
comment within the comment, which messes a bunch of things up.
Unfortunately, in this instance, I think the only fix is to delete the
form entirely, then upload the revised form. Note that form deletion can
take a while if you have many form submissions (it has to delete all the
submissions individually before the form can be removed).
Do you have submission data that you need to preserve on this server? If
so, let me know, as you will require a hacked version of ODK Briefcase to
access it before deleting the form.
This is all because the inserted comment prevents XML parsing to succeed
on the altered form, causing all sorts of things to break.
Going forward, as long as your licensing comment does not itself contain
a '>' character, you should be able to retain the licensing comment
at the front of your file. I've created this issue for the erroneous
timestamp comment insertion logic:
http://code.google.com/p/opendatakit/issues/detail?id=716
Mitch
On Tue, Oct 30, 2012 at 7:29 AM, Christopher Robert < chrislrobert@gmail.com> wrote:
Hi Kihara,
This sounds complicated!
There was an issue with these comments in one of the Aggregate and/or
Collect versions. Mitch should be online soon so maybe he can enlighten..?
Chris
P.S. Again, though, the exact error messages might be helpful when you
say that things fail. The uploads give specific error messages, and the
form download on Collect as well. Mitch (or I) might be able to give a
better answer if presented with the exact errors.
On Tuesday, October 30, 2012, Kihara Absolomon wrote:
Hi Chris,
Thanks a lot for that pointer, it worked, at least to the point of
replacing the older version. I was a bit sceptical at first as the older
version did not have the version attribute specified, but all went ok. But
I am afraid thats where the good news end.
On uploading the new version, I have noticed that you are adding a
comment of when the form was uploaded and from which url. Something like "
". My form has a GNU licence from
the second line, which goes all the way to the 22nd line. The comment
Aggregate adds is added within my GNU licence which is a comment resulting
to something like:
Copyright 2012 ILRI
This is a standalone XForm to be used with ODK.
This is a free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This XForm is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this XForm. If not, see http://www.gnu.org/licenses/.
-->
Assuming the uploaded form(Above snippet) has id='usda_goats_v3' and
version='2012103001'
- When trying to upload a newer version of the form
(id='usda_goats_v3' and version='2012103002'), the upload fails!
The only change is the removal of the license snippet.
- When I change the ID only (id='usda_goats_v5' and version='
2012103002') of the form, the upload to Aggregate succeeds.
- When I use the same id and version (id='usda_goats_v3' and
version='2012103001') on a new form (no change whatsoever), the
upload fails.
- On ODK Collect on the phone, when I tried downloading the
uploaded version(id='usda_goats_v3' and version='2012103001') the
download fails!
- On ODK Collect, I am able to download a form with a new id
(id='usda_goats_v5' and version='2012103002').
Might the comment which is being added by Aggregate cause all this
chaos?
Thanks
Kihara
On Tue, Oct 30, 2012 at 3:30 PM, Christopher Robert < chrislrobert@gmail.com> wrote:
Hi Kihara,
Did you update the version number? From the release notes:
Whenever a form or any of its media files are modified, the version
attribute in the top-level element (where the form id is defined) must be
changed. Version attributes are recommended to be of the form "yyyymmddnn",
e.g., 2012060400 -- the last two digits are the form iteration
within the given day. They must be integer values and the new value must
compare lexically greater than the prior value (this means, for example,
since "9" compares lexically greater than "10", you cannot update a version
from 9 to 10 -- but you could upgrade from "09" to "10").
If you did and you still get an error, can you post the exact error
text? I thought that we'd tested the constraints-changing case pretty well.
As a last resort, you can get to the bottom of the problem by going
back to your original form and then just changing one thing at a time.
Actually, you can start with no changes: if you re-upload what you think is
the original form, does Aggregate accept it? (It accepts unchanged forms.)
Then, change one constraint. Does that work? And so on. That way, you can
pin-point the change that's tripping it up.
Best,
Chris
On Tuesday, October 30, 2012, Kihara Absolomon wrote:
Dear Chris, ODK Developers,
I have to exploit the ODK Aggregate feature that allows some
metadata in a form to change and the form to be still uploadable. In
particular, I changed all constraints in a form from true to false and
proceeded to upload this form. However, the form couldn't be uploaded as
Aggregate complains of a duplicate form existing.
I am already using Aggregate v1.2, and on the form, changed nothing
else apart from the constraints. Even the form id remained constant.
What should I do to have Aggregate accept the new form with the
changes?
Kihara Absolomon :: Software Developer :: Movert Technologies :: +254
733 567 797 :: http://soloincc.movert.co.ke/
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying to
produce bigger and better idiots. So far, the Universe is winning." – Rick
Cook
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com
--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com