[sqlite] [RFE bug] Improve error reporting for foreign keys

This is just a request-for-enhancement bug report, I've went to the trouble or reproducing this problem in a simple test case and while I probably wont be able to immediately benefit from an upstream fix for this, I hope that this bug report will be perceived as helpful and entered into your

Re: [sqlite] [RFE bug] Improve error reporting for foreign keys

On Mon, 2014-10-27 at 15:49 +0900, Tristan Van Berkom wrote: > This is just a request-for-enhancement bug report, I've went to the > trouble or reproducing this problem in a simple test case and while > I probably wont be able to immediately benefit from an upstream fix > for this, I hope that

Re: [sqlite] [RFE bug] Improve error reporting for foreign keys

On 10/27/2014 01:49 PM, Tristan Van Berkom wrote: This is just a request-for-enhancement bug report, I've went to the trouble or reproducing this problem in a simple test case and while I probably wont be able to immediately benefit from an upstream fix for this, I hope that this bug report will

Re: [sqlite] [RFE bug] Improve error reporting for foreign keys

Tristan Van Berkom wrote: > locateFKeyIndex() function issuing the not-so-informative > message "foreign key mismatch" [...] > > o When foreign keys are enabled at CREATE TABLE time, it would > be very helpful at this point to issue an error if a foreign > key is declared which refers to

Re: [sqlite] [RFE bug] Improve error reporting for foreign keys

On 27 Oct 2014, at 8:17am, Clemens Ladisch wrote: > Tristan Van Berkom wrote: >> locateFKeyIndex() function issuing the not-so-informative >> message "foreign key mismatch" [...] >> >> o When foreign keys are enabled at CREATE TABLE time, it would >>be very helpful at

Re: [sqlite] quasi-bug related to locking, and attached databases....

SQLite treats each attached database as a separate entity. Attaching the same file twice is just asking for problems. The query specifies that the destination db be locked for write and the source db for read; which translates to two locks that cannot coexist on one underlying db file.

Re: [sqlite] quasi-bug related to locking, and attached databases....

On Mon, Oct 27, 2014 at 9:23 AM, Hick Gunter wrote: > SQLite treats each attached database as a separate entity. Attaching the > same file twice is just asking for problems. > > The query specifies that the destination db be locked for write and the > source db for read; which

Re: [sqlite] [RFE bug] Improve error reporting for foreign keys

On Mon, 2014-10-27 at 09:17 +0100, Clemens Ladisch wrote: > Tristan Van Berkom wrote: > > locateFKeyIndex() function issuing the not-so-informative > > message "foreign key mismatch" [...] > > > > o When foreign keys are enabled at CREATE TABLE time, it would > > be very helpful at this

Re: [sqlite] quasi-bug related to locking, and attached databases....

On 27 Oct 2014, at 8:43am, Stephan Beal wrote: > - a couple months back Simon suggested ATTACHing the db to itself so that > we can effectively alias "main" to the well-known name we have specified > for that db instance. It worked like a charm until Dave discovered this

Re: [sqlite] quasi-bug related to locking, and attached databases....

On Mon, Oct 27, 2014 at 9:58 AM, Simon Slavin wrote: > > On 27 Oct 2014, at 8:43am, Stephan Beal wrote: > > > - a couple months back Simon suggested ATTACHing the db to itself so that > > we can effectively alias "main" to the well-known name we have

[sqlite] Circular References [Was: Re: [RFE bug] Improve error reporting for foreign keys]

[Changing subject line as this strays away from the original topic] On Mon, 2014-10-27 at 08:22 +, Simon Slavin wrote: > On 27 Oct 2014, at 8:17am, Clemens Ladisch wrote: > > > Tristan Van Berkom wrote: > >> locateFKeyIndex() function issuing the not-so-informative > >>

Re: [sqlite] Circular References [Was: Re: [RFE bug] Improve error reporting for foreign keys]

On 27 Oct 2014, at 9:11am, Tristan Van Berkom wrote: > This seems to me to be an elegant solution, but I'd be curious to > know if it would be considered badly designed for some reason, and > would be interested to know what kind of alternatives people would > propose.

Re: [sqlite] quasi-bug related to locking, and attached databases....

How about always referencing all tables via attached db names? That way, "main" is never referenced, neither explicitly nor implicitly, and is therefore never locked. -Ursprüngliche Nachricht- Von: Stephan Beal [mailto:sgb...@googlemail.com] Gesendet: Montag, 27. Oktober 2014 09:43 An:

Re: [sqlite] quasi-bug related to locking, and attached databases....

On Mon, Oct 27, 2014 at 10:44 AM, Hick Gunter wrote: > How about always referencing all tables via attached db names? That way, > "main" is never referenced, neither explicitly nor implicitly, and is > therefore never locked. > It's looking more and more as if that's what

Re: [sqlite] quasi-bug related to locking, and attached databases....

On Mon, Oct 27, 2014 at 11:08 AM, Stephan Beal wrote: > - TEMP tables get created in the MAIN db (assuming my memory of the docs > is correct), which means we can (though accidental misuse or carelessness) > end up filling up RAM with temporary tables (which we use

Re: [sqlite] quasi-bug related to locking, and attached databases....

TEMP tables get created in database temp; which is located in "a file" or "in memory" depending on the SQLITE_TEMP_STORE preprocessor symbol and the pragma temp_store. -Ursprüngliche Nachricht- Von: Stephan Beal [mailto:sgb...@googlemail.com] Gesendet: Montag, 27. Oktober 2014 11:44 An:

Re: [sqlite] quasi-bug related to locking, and attached databases....

On Mon, Oct 27, 2014 at 11:53 AM, Hick Gunter wrote: > TEMP tables get created in database temp; which is located in "a file" or > "in memory" depending on the SQLITE_TEMP_STORE preprocessor symbol and the > pragma temp_store. > Which reveals my ignorance on the topic ;). IIRC

Re: [sqlite] FTS pagination

Just to be clear. It basically means that after MATCH records are returned it iterates through ALL the rowids of the returned set and removes them from the set and orders them accordingly. -- View this message in context: http://sqlite.1065341.n5.nabble.com/FTS-pagination-tp78754p78849.html

[sqlite] Keeping -wal and -shm files

I have a database that is updated (written) by one user and read by another user. So I use WAL mode to get concurrency. I'm running Linux/ext4. Both users are members of the same group. The trouble is that Linux ignores the setgid bit on the directory, so when a user access the database, they

Re: [sqlite] Circular References [Was: Re: [RFE bug] Improve error reporting for foreign keys]

On Mon, Oct 27, 2014 at 4:19 AM, Simon Slavin wrote: > A foreign key which points to the same table had not occurred to me, outside > of abstract mathematical exercises. I think you've come up with an > acceptable example of why I felt reluctant to condemn the practise.

Re: [sqlite] Keeping -wal and -shm files

On Mon, 27 Oct 2014 12:33:59 +0100 Steinar Midtskogen wrote: > Is there a way to prevent the -wal and -shm files from being deleted > after use, so that I can have them always have the right group? Or is > there a way to tell Linux to observe the setgid flag on a

Re: [sqlite] A new extension for sqlite to analyze the stringmetrics

Andrea, any chance I can download the latest version of the DLL? thanks gert 2014-09-28 23:28 GMT+02:00 aperi2007 : > Hi Keith, > thx for hints. > I have apply all of them. > > The only one I like to explain: > > I know the warning for the void insted of int declaration of

Re: [sqlite] A new extension for sqlite to analyze the stringmetrics

Sorry, stupid me... I clicked on the wrong link. 2014-10-27 17:32 GMT+01:00 Gert Van Assche : > Andrea, any chance I can download the latest version of the DLL? > > thanks > > gert > > 2014-09-28 23:28 GMT+02:00 aperi2007 : > >> Hi Keith, >> thx for hints.

Re: [sqlite] Keeping -wal and -shm files

"James K. Lowden" writes: > See -o grpid in mount(8). I think that's what you want. Thanks. It works! -- Steinar ___ sqlite-users mailing list sqlite-users@sqlite.org

Re: [sqlite] Keeping -wal and -shm files

On Mon, 2014-10-27 at 12:27 -0400, James K. Lowden wrote: > On Mon, 27 Oct 2014 12:33:59 +0100 > Steinar Midtskogen wrote: > > > Is there a way to prevent the -wal and -shm files from being deleted > > after use, so that I can have them always have the right group? Or is

[sqlite] compile question

I am using SQLite on a small webproject and I usually use MySQL. As we know in MySQL there is a user/pass authentication to the DB. In the File tree onthe SQLite site I can see in the /ext directory the userauth folder. It seems like this is not enabled by default. So I started reading

Re: [sqlite] quasi-bug related to locking, and attached databases....

On Mon, Oct 27, 2014 at 11:59 AM, Stephan Beal wrote: > On Mon, Oct 27, 2014 at 11:53 AM, Hick Gunter wrote: > >> TEMP tables get created in database temp; which is located in "a file" or >> "in memory" depending on the SQLITE_TEMP_STORE preprocessor

Re: [sqlite] quasi-bug related to locking, and attached databases....

On Mon, Oct 27, 2014 at 3:23 AM, Hick Gunter wrote: > SQLite treats each attached database as a separate entity. Attaching the same > file twice is just asking for problems. Well, it could do something to detect duplicates, but it may not be easy (or even possible) to portably

Re: [sqlite] quasi-bug related to locking, and attached databases....

On Mon, Oct 27, 2014 at 8:52 PM, Nico Williams wrote: > Well, it could do something to detect duplicates, but it may not be > easy (or even possible) to portably detect that two DB files are the > same file. The same is true for the application, of course, but it > seems

Re: [sqlite] quasi-bug related to locking, and attached databases....

On Mon, Oct 27, 2014 at 3:17 PM, Stephan Beal wrote: > That's conceptually the same problem we're trying to solve here: keep the > public db names stable, regardless of where/how they're actually attached. Yes, I think that's desirable. If it's not too much to ask for

Re: [sqlite] quasi-bug related to locking, and attached databases....

On 27 Oct 2014, at 9:49pm, Nico Williams wrote: > On Mon, Oct 27, 2014 at 3:17 PM, Stephan Beal wrote: >> That's conceptually the same problem we're trying to solve here: keep the >> public db names stable, regardless of where/how they're actually

Re: [sqlite] quasi-bug related to locking, and attached databases....

On Mon, Oct 27, 2014 at 5:12 PM, Simon Slavin wrote: > On 27 Oct 2014, at 9:49pm, Nico Williams wrote: >> If it's not too much to ask for then SQLite3 ought to: a) check for >> duplicates by canonicalized path (but keep in mind that this can be >>

Re: [sqlite] quasi-bug related to locking, and attached databases....

On Mon, 27 Oct 2014 16:49:42 -0500 Nico Williams wrote: > If it's not too much to ask for then SQLite3 ought to: a) check for > duplicates by canonicalized path (but keep in mind that this can be > difficult to do portably, or without obnoxious length limitations on >