Skip to content
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

Binding of boolean true/false values is not 100% correct #545

Open
brodybits opened this issue Sep 1, 2016 · 2 comments
Open

Binding of boolean true/false values is not 100% correct #545

brodybits opened this issue Sep 1, 2016 · 2 comments

Comments

@brodybits
Copy link
Contributor

Both Web SQL and this plugin bind boolean true and false values as string values ("true" and "false"). The change in andpor/react-native-sqlite-storage#61 which was eventually accepted fixed andpor / react-native-sqlite-storage to bind true and false as 1 and 0. As I said in andpor/react-native-sqlite-storage#63 (comment) I think change in andpor/react-native-sqlite-storage#61 is correct:

I think we can deduce that PR #61 (andpor/react-native-sqlite-storage#61) is correct according to the draft Web SQL database standard [1] sections 4.2 and 5 (released in November 2010). Section 4.2 [2] specifies how to bind each "?" placeholder. According to section 5 [3]:

User agents must implement the SQL dialect supported by Sqlite 3.6.19.

When converting bound arguments to SQL data types, the JavaScript ToPrimitive abstract operation must be applied to obtain the raw value to be processed. [ECMA262].

We generally support SQLite 3.7.x and 3.8.x which should be very close to the "SQL dialect" supported by SQLite 3.6.19. According to ECMA 262 5.1 [4](June 2011) section 9.1 [5] there is no conversion from the Boolean type. Then according to [6] SQLite 3.x.x: "Boolean values are stored as integers 0 (false) and 1 (true)."

I am now considering whether or not to apply a similar fix to the Cordova sqlite plugin.

[1] https://www.w3.org/TR/webdatabase/
[2] https://www.w3.org/TR/webdatabase/#parsing-and-processing-sql-statements
[3] https://www.w3.org/TR/webdatabase/#web-sql
[4] http://www.ecma-international.org/ecma-262/5.1/
[5] http://www.ecma-international.org/ecma-262/5.1/#sec-9.1
[6] https://www.sqlite.org/datatype3.html#section_2_1

I am mixed whether or not to fix this. (I am leaning towards it right now.) Some major benefits I can think of:

  • one less deviation from the spec
  • possible benefit for an experienced SQLite user who depends on the statement in https://www.sqlite.org/datatype3.html#section_2_1: "... Boolean values are stored as integers 0 (false) and 1 (true)."
  • one less bug/deviation to document
  • New applications would not depend on non-compliant behavior. I can think of the following example: An application could depend on using boolean true/false in JavaScript and expect the string value ("true"/"false") to actually show up somewhere such as a human-readable report document or GUI.

Some drawbacks:

  • Yet another difference from Web SQL behavior that could potentially affect an experienced Web SQL developer and would need to be documented
  • Change in behavior from older versions that could potentially break an existing application. An application that is technically non-compliant could depend on using boolean true/false in JavaScript and expects the string value ("true"/"false") to actually show up somewhere (such as a human-readable report document or GUI).

Any other comments and suggestions would be appreciated.

@etopian
Copy link

etopian commented Jan 3, 2018

+1

1 similar comment
@shineabel
Copy link

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants