Re: [sqlite] Query Planning Knowledge

Andy Bennett wrote: > I could use the inner join for the "entrys" join and the "items" join > but not the "entry-items" join because each entry can have more than > one item. WITH a(id, name) AS (VALUES (1, 'A')), b(id, name) AS (VALUES (1, 'B1'), (1, 'B2')) SELECT * FROM a INNER JOIN

Re: [sqlite] Query Planning Knowledge

Hi David, Thanks for your thoughtful reply. Can't go into as much detail as you. But a couple comments. "primary key unique" is redundant, and will actually create a redundant unique index. Are you refering to the CREATE TABLE clauses for the "items" and "registers" tables? I appear

Re: [sqlite] Query Planning Knowledge

Your description of the schema does not match the schema that you have shown. (As an aside, I wonder why you are using such confusing table and column names that require the puking of quotes all over the place? You can avoid such ugliness by searching and replacing all "-" with nothingness

Re: [sqlite] Query Planning Knowledge

Can't go into as much detail as you. But a couple comments. "primary key unique" is redundant, and will actually create a redundant unique index. "Do later version of SQLite manage to spot the constant propagation opportunity?" This requires way more algebra and proof than I think you realize.

Re: [sqlite] CoreData - when database gets closed

On 22 Jan 2019, at 3:45pm, Maldonado-Salazar, Carlos wrote: > Is there a way to know when CoreData closes sqlite files?. I’m using CoreData > in an iOS app and I set file attributes for sqlite file to be > NSFileProtectionCompleteUnlessOpen which throws away the key to encrypt the > file

Re: [sqlite] [EXTERNAL] Feature req: Shell .open command should inform user what file it opened

The other reason for this is to give you a chance to set a number of permanent pragmas that affect that first page that gets written. Page size, schema version, text encoding etc. But testing it right now it looks like when you use a non-existing file name, both .open and ATTACH do indeed

[sqlite] CoreData - when database gets closed

Is there a way to know when CoreData closes sqlite files?. I’m using CoreData in an iOS app and I set file attributes for sqlite file to be NSFileProtectionCompleteUnlessOpen which throws away the key to encrypt the file when it’s closed, denying access to it.

Re: [sqlite] [EXTERNAL] Feature req: Shell .open command should inform user what file it opened

IIRC SQLite will create a new database file only if (and when) the user enters a command that actually accesses the file. This avoids creating empty files if the user mistypes the file name. So the desired output might be required to appear "later". Use the already implemented flag -readonly

Re: [sqlite] SQLITE 3.26.0 compiler warning

Gary Sanders wrote: > shell.c(16466): warning C4996: 'strdup': The POSIX name for this item is > deprecated. strdup() is now in the dynamic memory TR: . The 'correct' way to get it is: #ifdef __STDC_ALLOC_LIB__ #define

[sqlite] Feature req: Shell .open command should inform user what file it opened

In the command shell, the .open command will either open an existing file or create a new one if it doesn't already exist. This can be confusing. It's even more confusing on Windows if the user has forgotten that the path should be written with forward slashes instead of the usual Windows

[sqlite] Query Planning Knowledge

Hi, I'm having some problems understanding what the query planner is doing and how to convince it to work in the way I want. Sorry that this is such a long and involved eMail. I've tried to describe my problem and show the steps I have taken in debugging it. I have made some effort to

[sqlite] SQLITE 3.26.0 compiler warning

When compiling the SQLITE 3.26.0 amalgamation in a C++ project for a Windows build, receive the following compiler warning: shell.c(16466): warning C4996: 'strdup': The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _strdup. See online help for details.

Re: [sqlite] Feedback on article about SQLITE_BUSY

> But both "single writer" and “multiple readers" remain true regardless of the > journal mode in use. And the same isolation semantics are provided either > way, no? It remains true, but I’m not sure if it's useful to understand isolation. I think isolation could be understood from multiple

Re: [sqlite] Feedback on article about SQLITE_BUSY

On 22 Jan 2019, at 8:21am, Rowan Worth wrote: > Transactions cannot see > any updates which occur after they have begun, and writers are serialised. Simon. ___ sqlite-users mailing list

Re: [sqlite] Feedback on article about SQLITE_BUSY

On Tue, 22 Jan 2019 at 12:51, Rahul Jayaraman wrote: > > I think "single writer, multiple readers" is the simplest way to describe > sqlite's approach to isolation > > I’m not sure if this summarization paints enough of a picture about how > SQLite restricts interleaving of read & write