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, "drhsql...@gmail.com on behalf of Richard Hipp"
<drhsql...@gmail.com on behalf of d...@sqlite.org> wrote:
On 6/26/17, Peter da Silva <peter.dasi...@flightaware.com> wrote:
> On 6/26/17, 11:15 AM, "drhsql...@gmail.com on behalf of Richard Hipp"
> <drhsql...@gmail.com on behalf of d...@sqlite.org> 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
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
