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
> Windows),
The name is not
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
>> difficult to do portably, or without obnoxious le
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 attached.
>
> Yes, I think that's desirable.
>
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 then SQLite3 ought to: a) c
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 reasonable [to me anyway
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 detect that two DB
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 symbol and the
>> pragma temp_store.
>>
>
> W
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 we aren't using a
ktober 2014 11:44
An: General Discussion of SQLite Database
Betreff: 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),
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 regularly to
> process large da
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 we'll have to do, but i
4 09:43
An: General Discussion of SQLite Database
Betreff: 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 ask
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 specified
> > for that db instance. It worked
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
> weird locking behaviou
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 translates to two l
.
-Ursprüngliche Nachricht-
Von: dave [mailto:d...@ziggurat29.com]
Gesendet: Sonntag, 26. Oktober 2014 00:36
An: 'General Discussion of SQLite Database'; sqlite-...@sqlite.org
Betreff: Re: [sqlite] quasi-bug related to locking, and attached databases
> -Original Message-
&
> -Original Message-
> From: sqlite-users-boun...@sqlite.org
> [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Stephan Beal
> Sent: Saturday, October 25, 2014 3:32 AM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] quasi-bug related to locki
On Fri, Oct 24, 2014 at 11:16 PM, Simon Slavin wrote:
> Which version of SQLite are you using ?
> What operating system are you using (including which version) ?
> What formats are the volumes those files are stored on ?
>
Simon, FYI: this is the "'main' db aliasing" problem i brought up a coupl
> -Original Message-
> From: sqlite-users-boun...@sqlite.org
> [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Simon Slavin
> Sent: Friday, October 24, 2014 4:45 PM
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] quasi-bug related to locki
On 24 Oct 2014, at 10:40pm, dave wrote:
> Later I can try on linux, but I don't have it at my fingertips just now. I
> don't mind trying with other versions of sqlite if you think it's helpful,
> but I suspect it's been there forever.
Not gonna ask for this since you've now given enough info f
> -Original Message-
> From: sqlite-users-boun...@sqlite.org
> [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Simon Slavin
...
> On 24 Oct 2014, at 9:54pm, dave wrote:
>
> > Can locking be made more clever to know about aux being an alias
> > for main, and effectively translate
On 24 Oct 2014, at 9:54pm, dave wrote:
> Can locking be made more clever to know about aux being an alias
> for main, and effectively translate the query shown to it's functional
> equivalent of:
>insert or replace into main.dest ( name, value ) values ('allow',(select
> value from main.sou
22 matches
Mail list logo
