This is really a pretty major change.
Our experience with the comparable options in Pgtcl and Speedtables is that
there is likely a lot of code that assumes that all array elements are set in
`$db eval “...” array { ... }` blocks that will error out with this change. I
don’t think I would be comfortable using this in existing code without doing an
extensive audit... and for third party packages getting changes propagated
upstream.
Making it a per-call option allows new code to use it safely, without impacting
any other components that might be using the same database.
On 6/26/17, 11:31 AM, "[email protected] on behalf of Richard Hipp"
<[email protected] on behalf of [email protected]> wrote:
On 6/26/17, Peter da Silva <[email protected]> wrote:
> On 6/26/17, 11:15 AM, "[email protected] on behalf of Richard Hipp"
> <[email protected] on behalf of [email protected]> wrote:
>> If you get the latest check-in (https://www.sqlite.org/src/info/trunk)
>> there is a new option on the "sqlite3" command called "-unsetnull 1"
which
>> causes "db eval" to work as you desire - by unsetting the array elements
>> for NULL values. This option is off by default for legacy compatibility.
>
> Could that be an option on the eval command rather than the db, so that
> packages can safely use the feature on databases they don’t “own”?
>
It is per-connection.
The change is sufficient minor and obscure that 99.9% of packages
should work the same regardless of the setting. The only reason for
making it an option rather than the only way things happen is for the
other 0.1% of application where it really will make a difference.
--
D. Richard Hipp
[email protected]
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
