We've been running this combination of Aggregate and Collect, since June and
hadn't noticed any issue until recently. Perhaps unrelated... I've added
additional xforms to Aggregate and then deleted them. Currently I have four
xforms showing on Aggregate, each with a different file name, name, and
identifier, but when I "Get New Forms" on ODK Collect, I only get one of
them. That is, the directory listing returns only one after I have
completely deleted all data and forms from Collect. Weird.
Then, when I refresh, I get the same one. ID: null. (which could be highly
relevant)
I see no smoking gun in the Android log. I've uninstalled Collect entirely,
then re-installed. Same behavior before and after. This makes me believe
it is the Aggregate version or interaction.
So -- Known issue? Upgrade Aggregate? To which version? [Migrating users
over is ok process, but I'd rather do only once in next few months. ] My
need is to change a form out with a new version and this is a problem in
getting that done. I'm comfortable with the Collect 1.1.7RC-1, and am
tempted to move to similar on Aggregate. Good idea?
One thing that I've foun out ODK Collect 1.1.7 does and 1.1.5 didn't is
that when it downloads the formList, forms with the same ID "override"
each other, or at least, forms with a null ID override any other form
with a null ID: hence, if all your forms being served have a null ID,
Collect only shows one form, the last one.
I don't know whether this is expected behavior or a bug (It's certainly
a backward incompatibility so either it is a bug in 1.1.7 or it was a
bug in 1.1.5 allowing multiple forms with same id or null id)
This narrows down your issue to finding out why the ID's of your forms
are being seen as null in the first place.
···
On 09/26/2011 05:23 AM, James Dailey wrote:
> Currently I
> have four xforms showing on Aggregate, each with a different file name,
> name, and identifier, but when I "Get New Forms" on ODK Collect, I only
> get one of them.
> I get the same one. ID: null.
the proof that there is another interaction going comes from the fact that
after I switched up to use Aggregate 1.0-RC1, the error behavior on Collect
1.1.7RC-1 goes away. So, it appears that there is a data corruption issue
(at the level of the form definition) on my instance of Aggregate 0.9.6.
I.e. the instance was running ok and able to add new forms until recently.
James
···
On Mon, Sep 26, 2011 at 2:43 AM, Matteo Sisti Sette < matteosistisette@gmail.com> wrote:
On 09/26/2011 05:23 AM, James Dailey wrote:
Currently I
have four xforms showing on Aggregate, each with a different file name,
name, and identifier, but when I "Get New Forms" on ODK Collect, I only
get one of them.
I get the same one. ID: null.
One thing that I've foun out ODK Collect 1.1.7 does and 1.1.5 didn't is
that when it downloads the formList, forms with the same ID "override" each
other, or at least, forms with a null ID override any other form with a null
ID: hence, if all your forms being served have a null ID, Collect only shows
one form, the last one.
I don't know whether this is expected behavior or a bug (It's certainly a
backward incompatibility so either it is a bug in 1.1.7 or it was a bug in
1.1.5 allowing multiple forms with same id or null id)
This narrows down your issue to finding out why the ID's of your forms are
being seen as null in the first place.
the proof that there is another interaction going comes from the fact
that after I switched up to use Aggregate 1.0-RC1, the error behavior on
Collect 1.1.7RC-1 goes away.
I guess Aggregate 1.0 serves the formList in the new OpenRosa-compliant
way, which is understood correctly by Collect 1.1.7 and is different
from the old formList format served by Aggregate 0.9.
Collect 1.1.7 detects which format the formList is, and it is supposed
to parse an old-style form list in the old way, but 1.1.7's way of
interpreting the legacy list is NOT identical to 1.1.5's way.
(((
By looking at ODK Collect source code, it seems that it expects an
old-style formList to be like this:
id1
name1
id2
name2
...
Is this really the way old formList were served?? It looks to me pretty
strange, I would rather expect formID to be an attribute of the form
tag.....
)))
A part from this, 1.1.7 treats multiple forms in the list with null id
as if they were "the same" form, while 1.1.5 didn't, but I don't know if
this is an intentional backward-compatibility break.
···
On Mon, Sep 26, 2011 at 10:38 AM, Matteo Sisti Sette < matteosistisette@gmail.com> wrote:
On 09/26/2011 07:22 PM, James Dailey wrote:
the proof that there is another interaction going comes from the fact
that after I switched up to use Aggregate 1.0-RC1, the error behavior on
Collect 1.1.7RC-1 goes away.
I guess Aggregate 1.0 serves the formList in the new OpenRosa-compliant
way, which is understood correctly by Collect 1.1.7 and is different from
the old formList format served by Aggregate 0.9.
Collect 1.1.7 detects which format the formList is, and it is supposed to
parse an old-style form list in the old way, but 1.1.7's way of interpreting
the legacy list is NOT identical to 1.1.5's way.
(((
By looking at ODK Collect source code, it seems that it expects an
old-style formList to be like this:
id1
name1
id2
name2
...
Is this really the way old formList were served?? It looks to me pretty
strange, I would rather expect formID to be an attribute of the form
tag.....
)))
A part from this, 1.1.7 treats multiple forms in the list with null id as
if they were "the same" form, while 1.1.5 didn't, but I don't know if this
is an intentional backward-compatibility break.
I'm having a similar problem (reported it a few weeks back).
Wondering if anyone with the issue has confirmed that upgrading to
Aggregate v1_0 resolves it? Are there instructions anywhere by the
way for upgrading a Google appspot installation from 0.9.x? Would I
lose any data already collected and are there any compatibility issues
with the older forms on the new aggregate? Cheers!
···
On Sep 27, 8:41 pm, Mitch Sundt wrote:
> The 0.9.x problem and the showing of only one form is here: *http://code.google.com/p/opendatakit/issues/detail?id=298*
>
> If you can, please search the open issues list to see if the issue is
> already reported before sending to the list.
> http://code.google.com/p/opendatakit/issues/list
>
> Mitch
>
> On Mon, Sep 26, 2011 at 10:38 AM, Matteo Sisti Sette < matteosistise...@gmail.com> wrote:
> > On 09/26/2011 07:22 PM, James Dailey wrote:
>
> > - the proof that there is another interaction going comes from the fact
> >> that after I switched up to use Aggregate 1.0-RC1, the error behavior on
> >> Collect 1.1.7RC-1 goes away.
>
> > I guess Aggregate 1.0 serves the formList in the new OpenRosa-compliant
> > way, which is understood correctly by Collect 1.1.7 and is different from
> > the old formList format served by Aggregate 0.9.
> > Collect 1.1.7 detects which format the formList is, and it is supposed to
> > parse an old-style form list in the old way, but 1.1.7's way of interpreting
> > the legacy list is NOT identical to 1.1.5's way.
>
> > (((
> > By looking at ODK Collect source code, it seems that it expects an
> > old-style formList to be like this:
>
> >
> > id1
> > name1
> > id2
> > name2
> > ...
> >
>
> > Is this really the way old formList were served?? It looks to me pretty
> > strange, I would rather expect formID to be an attribute of the form
> > tag.....
> > )))
>
> > A part from this, 1.1.7 treats multiple forms in the list with null id as
> > if they were "the same" form, while 1.1.5 didn't, but I don't know if this
> > is an intentional backward-compatibility break.
>
> > --
> > Post: opendatakit@googlegroups.com
> > Unsubscribe: opendatakit+unsubscribe@**googlegroups.com
> > Options:http://groups.google.com/**group/opendatakit?hl=en
>
> --
> Mitch Sundt
> Software Engineerhttp://www.OpenDataKit.org
> University of Washington
> mitchellsu...@gmail.com
There will be a set of releases coming out shortly that will allow you
to upgrade from Aggregate 0.9.x to Aggregate 1.0.
Waylon
···
On Tue, Sep 27, 2011 at 9:43 PM, Pooya wrote:
> I'm having a similar problem (reported it a few weeks back).
> Wondering if anyone with the issue has confirmed that upgrading to
> Aggregate v1_0 resolves it? Are there instructions anywhere by the
> way for upgrading a Google appspot installation from 0.9.x? Would I
> lose any data already collected and are there any compatibility issues
> with the older forms on the new aggregate? Cheers!
>
>
>
>
> On Sep 27, 8:41 pm, Mitch Sundt wrote:
>> The 0.9.x problem and the showing of only one form is here: *http://code.google.com/p/opendatakit/issues/detail?id=298*
>>
>> If you can, please search the open issues list to see if the issue is
>> already reported before sending to the list.
>> http://code.google.com/p/opendatakit/issues/list
>>
>> Mitch
>>
>> On Mon, Sep 26, 2011 at 10:38 AM, Matteo Sisti Sette < matteosistise...@gmail.com> wrote:
>> > On 09/26/2011 07:22 PM, James Dailey wrote:
>>
>> > - the proof that there is another interaction going comes from the fact
>> >> that after I switched up to use Aggregate 1.0-RC1, the error behavior on
>> >> Collect 1.1.7RC-1 goes away.
>>
>> > I guess Aggregate 1.0 serves the formList in the new OpenRosa-compliant
>> > way, which is understood correctly by Collect 1.1.7 and is different from
>> > the old formList format served by Aggregate 0.9.
>> > Collect 1.1.7 detects which format the formList is, and it is supposed to
>> > parse an old-style form list in the old way, but 1.1.7's way of interpreting
>> > the legacy list is NOT identical to 1.1.5's way.
>>
>> > (((
>> > By looking at ODK Collect source code, it seems that it expects an
>> > old-style formList to be like this:
>>
>> >
>> > id1
>> > name1
>> > id2
>> > name2
>> > ...
>> >
>>
>> > Is this really the way old formList were served?? It looks to me pretty
>> > strange, I would rather expect formID to be an attribute of the form
>> > tag.....
>> > )))
>>
>> > A part from this, 1.1.7 treats multiple forms in the list with null id as
>> > if they were "the same" form, while 1.1.5 didn't, but I don't know if this
>> > is an intentional backward-compatibility break.
>>
>> > --
>> > Post: opendatakit@googlegroups.com
>> > Unsubscribe: opendatakit+unsubscribe@**googlegroups.com
>> > Options:http://groups.google.com/**group/opendatakit?hl=en
>>
>> --
>> Mitch Sundt
>> Software Engineerhttp://www.OpenDataKit.org
>> University of Washington
>> mitchellsu...@gmail.com
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>