First review #820
The function follows RFC 7386 JSON Merge Patch semantics:
* If the patch is null, the target is replaced with null
* If the patch contains a scalar value, the target is replaced with that
value
* If both target and patch are objects, the patch is recursively applied
* null values in the patch result in property removal from the target
Closes#821
Change JSON deserialization to enable json_patch implementation with
SQLite-compatible behavior:
* Preserves duplicate keys in JSON objects
* Applies patches only to the first occurrence of each key
* Trade-off: Changes key lookup from O(1) to O(n) to support duplicate
keys
* Have to be merged before json_patch() function
Closes#820
Json serialization logic was pulled from serde_json. Google's json5
serialization code was not flexible enough to allow for pretty printing
json, so I believe that the formatter design is a good layer to abstract
this logic. This refactor will trivially enable the implementation of
json_pretty function from sqlite. My other PR for json_quote, #763,
depends a tiny bit on a helper utility from the previous serialization
implementation. If this PR is considered first, I will change the code
in my other PR to account for this.
Reviewed-by: Diego Reis (@diegoreis42)
Reviewed-by: Kacper Madej (@madejejej)
Closes#771
This simple patch makes sure we can operate with a reference to the
string instead of being forced to transform it to a string, and makes
sure that the Arc doesn't have to be cloned (which can be expensive in
multi-core systems).
This doesn't really make a large difference in benchmarks, given how
expensive Parse::new() is.
Reviewed-by: Preston Thorpe (@PThorpe92)
Closes#808
This simple patch makes sure we can operate with a reference to the
string instead of being forced to transform it to a string, and makes
sure that the Arc doesn't have to be cloned (which can be expensive in
multi-core systems).
This doesn't really make a large difference in benchmarks, given how
expensive Parse::new() is.
The first rule of writing fast programs: don't use dynamic memory
allocation!
Brings back some performance for the `SELECT 1` micro-benchmark,
although we're still not where we need to be.
This WIP driver uses the [purego](github.com/ebitengine/purego) library,
that supports cross platform `Dlopen`/`Dlsym` and not a whole lot else.
I really didn't want to use CGO, have very little experience with WASM
and I heard nothing but good things about this library. It's very easy
to use and stable especially when you consider the use case here of 3
functions.
NOTE: The WIP state that this PR is in right at this moment, is not able
to run these simple queries. This screengrab was taken from a couple
days ago when I wrote up a quick demo to load the library, call a simple
query and had it println! the result to make sure everything was working
properly.
I am opening this so kind of like the Java bindings, I can incrementally
work on this. I didn't want to submit a massive PR, try to keep them at
~1k lines max. The state of what's in this PR is highly subject and
likely to change.
I will update when they are at a working state where they can be tested
out and make sure they work across platforms.
Closes#776
I think it is mostly correct, not so sure how to handle `BLOB`. One
thing that caught my attention is that sqlite seems to have a
optimization for trivial cases, saving some bytecodes, for instance:
I'm looking that right now.
Closes#777
Take the logical OR of the values in register P1 and P2 and store the answer in register P3. If either P1 or P2 is nonzero (true) then the result is 1 (true) even if the other input is NULL. A NULL and false or two NULLs give a NULL output.
Take the logical AND of the values in registers P1 and P2 and write the result into register P3. If either P1 or P2 is 0 (false) then the result is 0 even if the other input is NULL. A NULL and true or two NULLs give a NULL output.
