-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add non-string calculation types #70
Comments
also discussed here: XLSForm/xlsform.github.io#71 The bug is in javarosa unfortunately. There should be no problem storing the result as a string. An XPath evaluator has no knowledge of the datatype of expression function arguments or operands. |
Adding note: this does impact downstream processing. I.e., when we publish to Google Sheets or Fusion Tables, we use the field type in the XForm bind to configure the downstream server data type and storage format. So while I agree the JR expression evaluator should silently caste to the correct data type, this is still a spec issue within XLSForm, as it prevents publishing appropriately-typed fields in external datasets. |
Agreed. For that use case, it's a missing feature. Types: (I will just keep hoping the JavaRosa type casting bugs will get fixed). |
Or if it can be like the select prompt types: calculate i.e., with the optional second term being the type of the field. Defaulting to string. |
Yes, looks good to me. P.S. This will mean Enketo & ODK Aggregate users will start running into HTTP 500 responses from ODK Aggregate for this Aggregate bug when the integer or decimal calculation returns NaN, Infinity or -Infinity. |
Just for fun here is a hacky way to do this currently with |
another use case here: https://community.kobotoolbox.org/t/link-answer-to-geopoint/2446/7 TL/DR; Useful to geo datatype calculations so that servers (such as KoBo) know the data can be displayed on a map. |
Another related issue was reported on the ODK forum here. To summarize: a |
During discussion for #438, we agreed to implement this like this:
output: <bind nodeset="/data/c" type="dateTime" calculate="now()" /> The rule would become: If a question has a calculation but it has neither label nor hint value, it will not get a body element (just a This new rule builds upon the existing rule that a question without a calculation needs to have either a label or a hint to pass pyxform validation. This means that these two questions below would become equivalent (because "string" is the default type), and essentially
|
The approach described at #70 (comment) is now in |
EDIT: see #70 (comment) for the latest proposed approach.
Initial bug reported at https://groups.google.com/d/msg/opendatakit/eYFsVCLet1U/Wb4wZumGBAAJ
"The problem seems to be that the total_feld_calc field is stored as a "string" field, so the subsequent sum(${total_field_calc}) will fail with a type conversion failure."
The text was updated successfully, but these errors were encountered: