hello all,
i just pushed odk validate 1.3 to the website.
validate 1.3 is a minor release that updates the javarosa library so
it matches the version we are shipping in collect 1.1.5. the change
will ensure you get consistent validation error messages across both
applications.
yaw
Thanks, Yaw. This is a nice update. I have a few questions.
WARNING: choice value [...] is too long; max. suggested length 32 chars
Will a choice value with length longer than 32 characters mess up ODK
Collect or is this just a suggestion to work nicely with ODK Aggregate and
its siblings?
Should I use 'xmlns' or 'id' to identify XForms? It seems that Validate and
Collect have a preference for 'xmlns' but 'id' will still work.
ODK Validate doesn't seem to know about how to take pictures. Maybe I should
file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and will be
ignored: [mediatype] Location:
Problem found at nodeset: /html/body/upload
With element
Warning: 1 Unrecognized attributes found in Element [upload] and will be
ignored: [ref] Location:
Problem found at nodeset: /html/body/upload
With element
Thanks again,
Andrew
re: xmlns vs. id.
Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata standards
( https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema ), I
recommend using 'id' over 'xmlns' when naming a form. 'id' has the
advantage that we can eventually extend Aggregate to recognize different
versions of the same form through the treatment of 'version' and 'uiVersion'
tags.
Mitch
Thanks, Yaw. This is a nice update. I have a few questions.
WARNING: choice value [...] is too long; max. suggested length 32 chars
Will a choice value with length longer than 32 characters mess up ODK
Collect or is this just a suggestion to work nicely with ODK Aggregate and
its siblings?Should I use 'xmlns' or 'id' to identify XForms? It seems that Validate and
Collect have a preference for 'xmlns' but 'id' will still work.ODK Validate doesn't seem to know about how to take pictures. Maybe I
should file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and will be
ignored: [mediatype] Location:Problem found at nodeset: /html/body/uploadWith element
Warning: 1 Unrecognized attributes found in Element [upload] and will be
ignored: [ref] Location:Problem found at nodeset: /html/body/upload
With elementThanks again,
Andrew
On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa yanokwa@gmail.com wrote:
hello all,
i just pushed odk validate 1.3 to the website.
validate 1.3 is a minor release that updates the javarosa library so
it matches the version we are shipping in collect 1.1.5. the change
will ensure you get consistent validation error messages across both
applications.yaw
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitchellsundt@gmail.com
re: choice item length. i think there was a good reason for this, but
i don't remember. i've posted the question to the javarosa-developers
list (http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26)
and will let you know when i know.
"it is just a suggestion to avoid problems certain popular...
less-than-robust database backends. JR core handles it just fine."
-- drew
this shouldn't affect collect at all. pretty sure it doesn't affect
aggregate or build. i'm assuming mitch, waylon and clint will correct me if
i'm wrong.
to elaborate, in particular mysql supports a rather small total row size.
and if you have a survey with many questions that have long select values,
each column requires a large number of characters (it must be able to
accommodate the longest choice). before you know it, your form has too many
questions to fit into a database row.
"it is just a suggestion to avoid problems certain popular...
less-than-robust database backends. JR core handles it just fine."
-- drewthis shouldn't affect collect at all. pretty sure it doesn't affect
aggregate or build. i'm assuming mitch, waylon and clint will correct me if
i'm wrong.On Wed, Feb 23, 2011 at 11:38, Yaw Anokwa yanokwa@gmail.com wrote:
re: choice item length. i think there was a good reason for this, but
i don't remember. i've posted the question to the javarosa-developers
list (
http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26)
and will let you know when i know.On Tue, Feb 22, 2011 at 13:01, Mitch Sundt msundt@cs.washington.edu wrote:
re: xmlns vs. id.
Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata
standards
( https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema), I
recommend using 'id' over 'xmlns' when naming a form. 'id' has the
advantage that we can eventually extend Aggregate to recognize different
versions of the same form through the treatment of 'version' and
'uiVersion'
tags.Mitch
On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder < andrew.ei.marder@gmail.com> wrote:
Thanks, Yaw. This is a nice update. I have a few questions.
WARNING: choice value [...] is too long; max. suggested length 32 chars
Will a choice value with length longer than 32 characters mess up ODK
Collect or is this just a suggestion to work nicely with ODK Aggregate
and
its siblings?Should I use 'xmlns' or 'id' to identify XForms? It seems that Validate
and Collect have a preference for 'xmlns' but 'id' will still work.ODK Validate doesn't seem to know about how to take pictures. Maybe I
should file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and will
be
ignored: [mediatype] Location:Problem found at nodeset: /html/body/upload
With elementWarning: 1 Unrecognized attributes found in Element [upload] and will
be
ignored: [ref] Location:Problem found at nodeset: /html/body/upload
With elementThanks again,
Andrew
On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa yanokwa@gmail.com wrote:
hello all,
i just pushed odk validate 1.3 to the website.
validate 1.3 is a minor release that updates the javarosa library so
it matches the version we are shipping in collect 1.1.5. the change
will ensure you get consistent validation error messages across both
applications.yaw
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitchellsundt@gmail.com--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
I'm currently looking at adding a "length" attribute to tags for
string/select/select1 types which will provide a character-length hint for
the referenced nodeset; this enables more compact construction of the tables
holding the form data, as otherwise Aggregate 1.0 will allocate ~255
characters per field, leading to the aforementioned need to split a form
across multiple database tables due to the limitations of MySQL and/or
Postgres.
The length hint will not prevent strings exceeding that length from being
stored, but those longer strings will generally not be searchable because
they'll be stored in an large-object table (they can be retrieved, but not
pattern-matched against a search string by Aggregate 1.0).
Mitch
to elaborate, in particular mysql supports a rather small total row size.
and if you have a survey with many questions that have long select values,
each column requires a large number of characters (it must be able to
accommodate the longest choice). before you know it, your form has too many
questions to fit into a database row.On Wed, Feb 23, 2011 at 11:41 AM, Yaw Anokwa yanokwa@gmail.com wrote:
"it is just a suggestion to avoid problems certain popular...
less-than-robust database backends. JR core handles it just fine."
-- drewthis shouldn't affect collect at all. pretty sure it doesn't affect
aggregate or build. i'm assuming mitch, waylon and clint will correct me
if
i'm wrong.On Wed, Feb 23, 2011 at 11:38, Yaw Anokwa yanokwa@gmail.com wrote:
re: choice item length. i think there was a good reason for this, but
i don't remember. i've posted the question to the javarosa-developers
list (
http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26)
and will let you know when i know.On Tue, Feb 22, 2011 at 13:01, Mitch Sundt msundt@cs.washington.edu wrote:
re: xmlns vs. id.
Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata
standards
( https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema), I
recommend using 'id' over 'xmlns' when naming a form. 'id' has the
advantage that we can eventually extend Aggregate to recognize
different
versions of the same form through the treatment of 'version' and
'uiVersion'
tags.Mitch
On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder < andrew.ei.marder@gmail.com> wrote:
Thanks, Yaw. This is a nice update. I have a few questions.
WARNING: choice value [...] is too long; max. suggested length 32
chars
Will a choice value with length longer than 32 characters mess up ODK
Collect or is this just a suggestion to work nicely with ODK Aggregate
and
its siblings?Should I use 'xmlns' or 'id' to identify XForms? It seems that
Validate
and Collect have a preference for 'xmlns' but 'id' will still work.ODK Validate doesn't seem to know about how to take pictures. Maybe I
should file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and will
be
ignored: [mediatype] Location:Problem found at nodeset: /html/body/upload
With elementWarning: 1 Unrecognized attributes found in Element [upload] and will
be
ignored: [ref] Location:Problem found at nodeset: /html/body/upload
With elementThanks again,
Andrew
On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa yanokwa@gmail.com wrote:
hello all,
i just pushed odk validate 1.3 to the website.
validate 1.3 is a minor release that updates the javarosa library so
it matches the version we are shipping in collect 1.1.5. the change
will ensure you get consistent validation error messages across both
applications.yaw
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitchellsundt@gmail.com--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org http://www.opendatakit.org/
University of Washington
mitchellsundt@gmail.com
In MySQL, is a longtext field unsearchable?
Andrew
I'm currently looking at adding a "length" attribute to tags for
string/select/select1 types which will provide a character-length hint for
the referenced nodeset; this enables more compact construction of the tables
holding the form data, as otherwise Aggregate 1.0 will allocate ~255
characters per field, leading to the aforementioned need to split a form
across multiple database tables due to the limitations of MySQL and/or
Postgres.The length hint will not prevent strings exceeding that length from being
stored, but those longer strings will generally not be searchable because
they'll be stored in an large-object table (they can be retrieved, but not
pattern-matched against a search string by Aggregate 1.0).Mitch
On Wed, Feb 23, 2011 at 9:43 AM, Drew Roos droos@dimagi.com wrote:
to elaborate, in particular mysql supports a rather small total row size.
and if you have a survey with many questions that have long select values,
each column requires a large number of characters (it must be able to
accommodate the longest choice). before you know it, your form has too many
questions to fit into a database row.On Wed, Feb 23, 2011 at 11:41 AM, Yaw Anokwa yanokwa@gmail.com wrote:
"it is just a suggestion to avoid problems certain popular...
less-than-robust database backends. JR core handles it just fine."
-- drewthis shouldn't affect collect at all. pretty sure it doesn't affect
aggregate or build. i'm assuming mitch, waylon and clint will correct me
if
i'm wrong.On Wed, Feb 23, 2011 at 11:38, Yaw Anokwa yanokwa@gmail.com wrote:
re: choice item length. i think there was a good reason for this, but
i don't remember. i've posted the question to the javarosa-developers
list (
http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26)
and will let you know when i know.On Tue, Feb 22, 2011 at 13:01, Mitch Sundt msundt@cs.washington.edu wrote:
re: xmlns vs. id.
Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata
standards
( https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema), I
recommend using 'id' over 'xmlns' when naming a form. 'id' has the
advantage that we can eventually extend Aggregate to recognize
different
versions of the same form through the treatment of 'version' and
'uiVersion'
tags.Mitch
On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder < andrew.ei.marder@gmail.com> wrote:
Thanks, Yaw. This is a nice update. I have a few questions.
WARNING: choice value [...] is too long; max. suggested length 32
chars
Will a choice value with length longer than 32 characters mess up ODK
Collect or is this just a suggestion to work nicely with ODK
Aggregate and
its siblings?Should I use 'xmlns' or 'id' to identify XForms? It seems that
Validate
and Collect have a preference for 'xmlns' but 'id' will still work.ODK Validate doesn't seem to know about how to take pictures. Maybe I
should file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and will
be
ignored: [mediatype] Location:Problem found at nodeset: /html/body/upload
With elementWarning: 1 Unrecognized attributes found in Element [upload] and will
be
ignored: [ref] Location:Problem found at nodeset: /html/body/upload
With elementThanks again,
Andrew
On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa yanokwa@gmail.com wrote:
hello all,
i just pushed odk validate 1.3 to the website.
validate 1.3 is a minor release that updates the javarosa library
so
it matches the version we are shipping in collect 1.1.5. the change
will ensure you get consistent validation error messages across
both
applications.yaw
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitchellsundt@gmail.com--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org http://www.opendatakit.org/
University of Washington
mitchellsundt@gmail.com
There are native limitations.
MySQL only uses the first 1024 characters for sorting, for example (see
http://dev.mysql.com/doc/refman/5.0/en/blob.html ).
Google's BigTable doesn't index long text fields, so querying and filtering
are not natively supported (see
http://code.google.com/appengine/docs/java/datastore/entities.html#Properties_and_Value_Types)
Aggregate 1.0 works around this by storing the first ~250 characters in a
searchable string, then storing the full text in these large text storage
areas. So we don't loose data. However, we only support searching on the
first ~250 characters through the Aggregate 1.0 user interface. This
originated as a BigTable limitation, but is retained in the implementation
largely because of the added code we'd have to write to handle searching
beyond that.
When I get the "length" attribute implemented, it would define the length
limit instead of the generic "~250" character limit. With the caveat that
Google BigTable has a hard cap of 500 characters.
Mitch
In MySQL, is a longtext field unsearchable?
Andrew
On Wed, Feb 23, 2011 at 1:51 PM, Mitchell Sundt msundt@cs.washington.eduwrote:
I'm currently looking at adding a "length" attribute to tags for
string/select/select1 types which will provide a character-length hint for
the referenced nodeset; this enables more compact construction of the tables
holding the form data, as otherwise Aggregate 1.0 will allocate ~255
characters per field, leading to the aforementioned need to split a form
across multiple database tables due to the limitations of MySQL and/or
Postgres.The length hint will not prevent strings exceeding that length from being
stored, but those longer strings will generally not be searchable because
they'll be stored in an large-object table (they can be retrieved, but not
pattern-matched against a search string by Aggregate 1.0).Mitch
On Wed, Feb 23, 2011 at 9:43 AM, Drew Roos droos@dimagi.com wrote:
to elaborate, in particular mysql supports a rather small total row size.
and if you have a survey with many questions that have long select values,
each column requires a large number of characters (it must be able to
accommodate the longest choice). before you know it, your form has too many
questions to fit into a database row.On Wed, Feb 23, 2011 at 11:41 AM, Yaw Anokwa yanokwa@gmail.com wrote:
"it is just a suggestion to avoid problems certain popular...
less-than-robust database backends. JR core handles it just fine."
-- drewthis shouldn't affect collect at all. pretty sure it doesn't affect
aggregate or build. i'm assuming mitch, waylon and clint will correct me
if
i'm wrong.On Wed, Feb 23, 2011 at 11:38, Yaw Anokwa yanokwa@gmail.com wrote:
re: choice item length. i think there was a good reason for this, but
i don't remember. i've posted the question to the javarosa-developers
list (
http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26)
and will let you know when i know.On Tue, Feb 22, 2011 at 13:01, Mitch Sundt msundt@cs.washington.edu wrote:
re: xmlns vs. id.
Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata
standards
(
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema ),
I
recommend using 'id' over 'xmlns' when naming a form. 'id' has the
advantage that we can eventually extend Aggregate to recognize
different
versions of the same form through the treatment of 'version' and
'uiVersion'
tags.Mitch
On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder < andrew.ei.marder@gmail.com> wrote:
Thanks, Yaw. This is a nice update. I have a few questions.
WARNING: choice value [...] is too long; max. suggested length 32
chars
Will a choice value with length longer than 32 characters mess up
ODK
Collect or is this just a suggestion to work nicely with ODK
Aggregate and
its siblings?Should I use 'xmlns' or 'id' to identify XForms? It seems that
Validate
and Collect have a preference for 'xmlns' but 'id' will still work.ODK Validate doesn't seem to know about how to take pictures. Maybe
I
should file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and
will be
ignored: [mediatype] Location:Problem found at nodeset: /html/body/upload
With elementWarning: 1 Unrecognized attributes found in Element [upload] and
will be
ignored: [ref] Location:Problem found at nodeset: /html/body/upload
With elementThanks again,
Andrew
On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa yanokwa@gmail.com wrote:
hello all,
i just pushed odk validate 1.3 to the website.
validate 1.3 is a minor release that updates the javarosa library
so
it matches the version we are shipping in collect 1.1.5. the
change
will ensure you get consistent validation error messages across
both
applications.yaw
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitchellsundt@gmail.com--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org http://www.opendatakit.org/
University of Washington
mitchellsundt@gmail.com--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitchellsundt@gmail.com
Very interesting, thanks for edumucating me. It's good to hear about these
limitations so I have an idea of what's going to bite me down the road.
Andrew
There are native limitations.
MySQL only uses the first 1024 characters for sorting, for example (see
http://dev.mysql.com/doc/refman/5.0/en/blob.html ).Google's BigTable doesn't index long text fields, so querying and filtering
are not natively supported (see
http://code.google.com/appengine/docs/java/datastore/entities.html#Properties_and_Value_Types)Aggregate 1.0 works around this by storing the first ~250 characters in a
searchable string, then storing the full text in these large text storage
areas. So we don't loose data. However, we only support searching on the
first ~250 characters through the Aggregate 1.0 user interface. This
originated as a BigTable limitation, but is retained in the implementation
largely because of the added code we'd have to write to handle searching
beyond that.When I get the "length" attribute implemented, it would define the length
limit instead of the generic "~250" character limit. With the caveat that
Google BigTable has a hard cap of 500 characters.Mitch
On Wed, Feb 23, 2011 at 10:55 AM, Andrew Marder < andrew.ei.marder@gmail.com> wrote:
In MySQL, is a longtext field unsearchable?
Andrew
On Wed, Feb 23, 2011 at 1:51 PM, Mitchell Sundt <msundt@cs.washington.edu wrote:
I'm currently looking at adding a "length" attribute to tags for
string/select/select1 types which will provide a character-length hint for
the referenced nodeset; this enables more compact construction of the tables
holding the form data, as otherwise Aggregate 1.0 will allocate ~255
characters per field, leading to the aforementioned need to split a form
across multiple database tables due to the limitations of MySQL and/or
Postgres.The length hint will not prevent strings exceeding that length from being
stored, but those longer strings will generally not be searchable because
they'll be stored in an large-object table (they can be retrieved, but not
pattern-matched against a search string by Aggregate 1.0).Mitch
On Wed, Feb 23, 2011 at 9:43 AM, Drew Roos droos@dimagi.com wrote:
to elaborate, in particular mysql supports a rather small total row
size. and if you have a survey with many questions that have long select
values, each column requires a large number of characters (it must be able
to accommodate the longest choice). before you know it, your form has too
many questions to fit into a database row.On Wed, Feb 23, 2011 at 11:41 AM, Yaw Anokwa yanokwa@gmail.com wrote:
"it is just a suggestion to avoid problems certain popular...
less-than-robust database backends. JR core handles it just fine."
-- drewthis shouldn't affect collect at all. pretty sure it doesn't affect
aggregate or build. i'm assuming mitch, waylon and clint will correct
me if
i'm wrong.On Wed, Feb 23, 2011 at 11:38, Yaw Anokwa yanokwa@gmail.com wrote:
re: choice item length. i think there was a good reason for this, but
i don't remember. i've posted the question to the javarosa-developers
list (
http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26)
and will let you know when i know.On Tue, Feb 22, 2011 at 13:01, Mitch Sundt msundt@cs.washington.edu wrote:
re: xmlns vs. id.
Going forward, with Aggregate 1.0 and the OpenRosa XForms metadata
standards
(
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema ),
I
recommend using 'id' over 'xmlns' when naming a form. 'id' has the
advantage that we can eventually extend Aggregate to recognize
different
versions of the same form through the treatment of 'version' and
'uiVersion'
tags.Mitch
On Sat, Feb 19, 2011 at 2:26 PM, Andrew Marder < andrew.ei.marder@gmail.com> wrote:
Thanks, Yaw. This is a nice update. I have a few questions.
WARNING: choice value [...] is too long; max. suggested length 32
chars
Will a choice value with length longer than 32 characters mess up
ODK
Collect or is this just a suggestion to work nicely with ODK
Aggregate and
its siblings?Should I use 'xmlns' or 'id' to identify XForms? It seems that
Validate
and Collect have a preference for 'xmlns' but 'id' will still work.ODK Validate doesn't seem to know about how to take pictures. Maybe
I
should file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and
will be
ignored: [mediatype] Location:Problem found at nodeset: /html/body/upload
With elementWarning: 1 Unrecognized attributes found in Element [upload] and
will be
ignored: [ref] Location:Problem found at nodeset: /html/body/upload
With elementThanks again,
Andrew
On Thu, Feb 17, 2011 at 1:44 PM, Yaw Anokwa yanokwa@gmail.com wrote:
hello all,
i just pushed odk validate 1.3 to the website.
validate 1.3 is a minor release that updates the javarosa library
so
it matches the version we are shipping in collect 1.1.5. the
change
will ensure you get consistent validation error messages across
both
applications.yaw
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitchellsundt@gmail.com--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org http://www.opendatakit.org/
University of Washington
mitchellsundt@gmail.com--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en--
Mitch Sundt
Software Engineer
http://www.OpenDataKit.org
University of Washington
mitchellsundt@gmail.com
To further clarify Aggregate 1.0 removes mysql's row size limitation
by automatically creating multiple tables to split the rows if needed.
Mitch's comments about the search able portion of a field/item are
correct. Aggregate can allow many long columns and avoid row size
limitations; however, right now you may not be able to search the long
text in a query.
How real a problem is this? Trying to touch type 250+ character fields would
be very taxing and speaking for myself I'd likely run down my evo battery on
the first long field.
-steve-
-- Painfully slowly typed on my htc EVO --
To further clarify Aggregate 1.0 removes mysql's row size limitation
by automatically creating multiple tables to split the rows if needed.
Mitch's comments about the search able portion of a field/item are
correct. Aggregate can allow many long columns and avoid row size
limitations; however, right now you may not be able to search the long
text in a query.Very interesting, thanks for edumucating me. It's good to hear about
these
limitations so I have an idea of what's going to bite me down the road.
AndrewThere are native limitations.
MySQL only uses the first 1024 characters for sorting, for example (see
http://dev.mysql.com/doc/refman/5.0/en/blob.html ).Google's BigTable doesn't index long text fields, so querying and
filtering are not natively supported (see
http://code.google.com/appengine/docs/java/datastore/entities.html#Properties_and_Value_Types
)
Aggregate 1.0 works around this by storing the first ~250 characters in
a
searchable string, then storing the full text in these large text
storage
areas. So we don't loose data. However, we only support searching on
the
first ~250 characters through the Aggregate 1.0 user interface. This
originated as a BigTable limitation, but is retained in the
implementation
largely because of the added code we'd have to write to handle searching
beyond that.When I get the "length" attribute implemented, it would define the
length
limit instead of the generic "~250" character limit. With the caveat
that
Google BigTable has a hard cap of 500 characters.Mitch
In MySQL, is a longtext field unsearchable?
AndrewI'm currently looking at adding a "length" attribute to tags
for
string/select/select1 types which will provide a character-length hint
for
the referenced nodeset; this enables more compact construction of the
tables
holding the form data, as otherwise Aggregate 1.0 will allocate ~255
characters per field, leading to the aforementioned need to split a
form
across multiple database tables due to the limitations of MySQL and/or
Postgres.The length hint will not prevent strings exceeding that length from
being stored, but those longer strings will generally not be
searchable
because they'll be stored in an large-object table (they can be
retrieved,
but not pattern-matched against a search string by Aggregate 1.0).Mitch
to elaborate, in particular mysql supports a rather small total row
size. and if you have a survey with many questions that have long
select
values, each column requires a large number of characters (it must be
able
to accommodate the longest choice). before you know it, your form has
too
many questions to fit into a database row."it is just a suggestion to avoid problems certain popular...
less-than-robust database backends. JR core handles it just fine."
-- drewthis shouldn't affect collect at all. pretty sure it doesn't affect
aggregate or build. i'm assuming mitch, waylon and clint will
correct
me if
i'm wrong.re: choice item length. i think there was a good reason for this,
but
i don't remember. i've posted the question to the
javarosa-developers
list
(
http://groups.google.com/group/javarosa-developers/t/4f53b22c71b18b26)
and will let you know when i know.re: xmlns vs. id.
Going forward, with Aggregate 1.0 and the OpenRosa XForms
metadata
standards
(
https://bitbucket.org/javarosa/javarosa/wiki/OpenRosaMetaDataSchema ), I
recommend using 'id' over 'xmlns' when naming a form. 'id' has
the
advantage that we can eventually extend Aggregate to recognize
different
versions of the same form through the treatment of 'version' and
'uiVersion'
tags.Mitch
Thanks, Yaw. This is a nice update. I have a few questions.
WARNING: choice value [...] is too long; max. suggested length
32
chars
Will a choice value with length longer than 32 characters mess
up
ODK
Collect or is this just a suggestion to work nicely with ODK
Aggregate and
its siblings?Should I use 'xmlns' or 'id' to identify XForms? It seems that
Validate
and Collect have a preference for 'xmlns' but 'id' will still
work.ODK Validate doesn't seem to know about how to take pictures.
Maybe I
should file this in an issue tracker.
Warning: 1 Unrecognized attributes found in Element [upload] and
will be
ignored: [mediatype] Location:Problem found at nodeset: /html/body/upload
With elementWarning: 1 Unrecognized attributes found in Element [upload] and
will be
ignored: [ref] Location:Problem found at nodeset: /html/body/upload
With elementThanks again,
Andrew
hello all,
i just pushed odk validate 1.3 to the website.
validate 1.3 is a minor release that updates the javarosa
library so
it matches the version we are shipping in collect 1.1.5. the
change
will ensure you get consistent validation error messages
across