Re: [sqlite] [EXTERNAL] Re: Things you shouldn't assume when you store names

2019-11-14 Thread Hick Gunter
>> A growing number of organisations now ask me for my DOB or my >> postcode, rather than my name, when looking me up. I think you just >> explained why. In my country we have an increasing number of foreign >> family names, which probably helps it along. > >UK postcodes are incredibly

[sqlite] Entity Framework Core support

2019-11-14 Thread Mike King
Hi All, I can see System.Data.Sqlite supports Entity Framework 6. Are there any plans to support Entity Framework Core? Apologies if this is a basic question! Cheers, Mike ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] Adding a record to a table with one value change

2019-11-14 Thread Simon Slavin
On 14 Nov 2019, at 10:27pm, Jake Thaw wrote: > Why not like this? > > insert into t (a, b, c, d, e, idate) > SELECT a, b, c, 'y', e, '2019-02-12' FROM t WHERE a = 'p001' ORDER BY > idate desc limit 1; Dammit. I thought I had tried this, and received a syntax error. Now I see that it was

Re: [sqlite] Adding a record to a table with one value change

2019-11-14 Thread Keith Medcalf
On Thursday, 14 November, 2019 15:27, Jake Thaw wrote: >Why not like this? >insert into t (a, b, c, d, e, idate) >SELECT a, b, c, 'y', e, '2019-02-12' FROM t WHERE a = 'p001' ORDER BY >idate desc limit 1; Or, if using bound paramaters (and you should be): insert into t (a, b, c, d, e, idate)

Re: [sqlite] SQLITE_DETERMINISTIC and custom function optimization

2019-11-14 Thread Keith Medcalf
Unfortunately that is not reliable either because the aux_data is specific to the context and each invocation within the statement can have a different context. What does work is if you use the undocumented cross-context aux_data by using a negative argument number (note, since this is

Re: [sqlite] Adding a record to a table with one value change

2019-11-14 Thread Jake Thaw
Why not like this? insert into t (a, b, c, d, e, idate) SELECT a, b, c, 'y', e, '2019-02-12' FROM t WHERE a = 'p001' ORDER BY idate desc limit 1; On Fri, Nov 15, 2019 at 9:19 AM Simon Slavin wrote: > > On 14 Nov 2019, at 10:06pm, Jose Isaias Cabrera wrote: > > > insert into t (a, b, c, d, e,

Re: [sqlite] Adding a record to a table with one value change

2019-11-14 Thread Simon Slavin
On 14 Nov 2019, at 10:06pm, Jose Isaias Cabrera wrote: > insert into t (a, b, c, d, e, idate) values > ( >(SELECT a FROM t WHERE a = 'p001' ORDER BY idate desc limit 1), >(SELECT b FROM t WHERE a = 'p001' ORDER BY idate desc limit 1), >(SELECT c FROM t WHERE a = 'p001' ORDER BY

[sqlite] Adding a record to a table with one value change

2019-11-14 Thread Jose Isaias Cabrera
Greetings! I have this table, create table t (n INTEGER PRIMARY KEY, a, b, c, d, e, idate); insert into t (a, b, c, d, e, idate) values ('p001', 1, 2, 'n', 4, '2019-02-11'); insert into t (a, b, c, d, e, idate) values ('p002', 2, 2, 'n', 4, '2019-02-11'); insert into t (a, b, c, d, e, idate)

Re: [sqlite] SQLITE_DETERMINISTIC and custom function optimization

2019-11-14 Thread Keith Medcalf
>On Thursday, 14 November, 2019 03:52, Dominique Devienne >wrote: >>On Sat, Nov 9, 2019 at 1:20 PM Mario M. Westphal wrote: >>> Thanks to all the friendly people who commented on my question. Much >>> appreciated :-) >>> I was able to solve this with a small trick: >>> I created a small

Re: [sqlite] Things you shouldn't assume when you store names

2019-11-14 Thread Eric
On Wed, 13 Nov 2019 17:18:05 -0700 SQLite mailing list sqlite-users@mailinglists.sqlite.org said 8>< Give up on names and use something else? (SSN, phone number, DOB…) None of the above are safe primary keys. I don't think there is any single combination which is. Eric -- ms fnd in a lbry

Re: [sqlite] Things you shouldn't assume when you store names

2019-11-14 Thread Keith Medcalf
On Thursday, 14 November, 2019 09:35, Eric wrote: >On Thu, 14 Nov 2019 00:24:09 + SQLite mailing list >sqlite-users@mailinglists.sqlite.org said >> A growing number of organisations now ask me for my DOB or my postcode, >> rather than my name, when looking me up. I think you just

Re: [sqlite] Things you shouldn't assume when you store names

2019-11-14 Thread Eric
On Wed, 13 Nov 2019 18:41:54 -0700 SQLite mailing list sqlite-users@mailinglists.sqlite.org said On Wednesday, 13 November, 2019 17:18, Warren Young wrote: 8>< ... Useless pricks having no need of a phone number usually get (911) 911-9111 ... It is totally out of order to dismiss _any_

Re: [sqlite] SQLITE_DETERMINISTIC and custom function optimization

2019-11-14 Thread Keith Medcalf
-- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. On Thursday, 14 November, 2019 03:52, Dominique Devienne wrote: >On Sat, Nov 9, 2019 at 1:20 PM Mario M. Westphal wrote: >> Thanks to all the friendly people who

Re: [sqlite] Things you shouldn't assume when you store names

2019-11-14 Thread Eric
On Thu, 14 Nov 2019 00:24:09 + SQLite mailing list sqlite-users@mailinglists.sqlite.org said 8>< A growing number of organisations now ask me for my DOB or my postcode, rather than my name, when looking me up. I think you just explained why. In my country we have an increasing number of

Re: [sqlite] Specific sqlite_autoindex_* missing in recent SQLite versions

2019-11-14 Thread David Raymond
Apparently it got smarter about "primary key unique" in 3.20.0 and stopped making the extra index when it's a without rowid table. Don't see anything about it in the release notes though. Even on the current release "primary key unique" will still make an extra index for the unique if it's a

Re: [sqlite] SQLITE_DETERMINISTIC and custom function optimization

2019-11-14 Thread Dominique Devienne
On Sat, Nov 9, 2019 at 1:20 PM Mario M. Westphal wrote: > Thanks to all the friendly people who commented on my question. Much > appreciated :-) > > I was able to solve this with a small trick: > I created a small 'state' struct with a rowid and the result (float) for > that row. > Sounds like

Re: [sqlite] SQLITE_DETERMINISTIC and custom function optimization

2019-11-14 Thread Dominique Devienne
On Fri, Nov 8, 2019 at 9:20 PM Keith Medcalf wrote: > [...] The optimizer is prone to calculating things more often than it > needs to, and is difficult to force to "materialize" things. Since your expensive function needs to be calculated for every row of the > table anyway, it would be better

Re: [sqlite] [EXTERNAL] Specific sqlite_autoindex_* missing in recent SQLite versions

2019-11-14 Thread Hick Gunter
Maybe you are confusing the autoindex logic by including superflous attributes: ... Id INTEGER NOT NULL PRIMARY KEY UNIQUE ... NOT NULL is enforced for WITHOUT ROWID tables and a single field PRIMARY KEY already implies UNIQUE, so no autoindex is required for Id This leaves only the autoindex

[sqlite] Specific sqlite_autoindex_* missing in recent SQLite versions

2019-11-14 Thread Vincas Dargis
Hi list, Accidentally, when performing VACUUM using rather old SQLite 3.16.2 (from Debian 8 stretch) binary on some database file created with more recent SQLite (like 3.29.0 available in Qt 5.13.2 or a bit older), I've discovered that database now has a few more `sqlite_autodinex_*` entries in