On Friday, 27 September, 2019 22:11, Roman Fleysher
wrote:
>Based on the link you provide, it looks like I need unix-none VFS and
>specify it as:
>ATTACH 'file:demo2.db?vfs=unix-none' AS demo2;
Yup. I think you can also do that when opening the file on the sqlite3_open_v2
call by using the
Based on the link you provide, it looks like I need unix-none VFS and specify
it as:
ATTACH 'file:demo2.db?vfs=unix-none' AS demo2;
FLoM will be ensuring sequential access. The journaling, as I understand, is
independent of locking and will still work. That is robustness to crashes will
Check out the alternate VFS implementations (linked earlier), and also the
available parameters that you can pass to the sqlite3_open_v2 interface when
using URI mode, such as perhaps using the standard unix vfs but passing the
nolock option to disable all file locking operations (but not the
I agree that overhead might grow exponentially with number of nodes trying to
access the database. But then I do not understand why FLoM can not provide
solution. It can enforce sequential access thus reducing the overhead.
And yes, I was trying the KISS approach: rely on GPFS to do the
Yeah, WAL mode cannot work over a remote connection as the WAL index is a
shared memory file -- which can only be accessed by processes on a single
computer.
If you are using FLoM to co-ordinate your "application" use of SQLite3, then
maybe you want to look at using the dotfile VFS which uses
The timeout is set to 50min !
The database is used to synchronize / manage tasks. A kind of job manager. Thus
each access is a quick search with small update or delete.
I looked at the WALL mode. I do not exactly understand how it works, but SQLite
developers warn not to use WALL over network
On Friday, 27 September, 2019 17:00, Roman Fleysher wrote:
>I am using SQLite over GPFS distributed file system. I was told it
>honestly implements file locking. I never experienced corruption. But it
>is slow in the sense that when many jobs from many compute nodes try to
>access the same
IF the LIKE optimization applied where the LHS of the like operator were an
expression, then the index on that expression would have to have the
appropriate collation. In otherwords for a case_insensitive_like (the default)
the index would have to be collate nocase in order to be useable, and
On 27 Sep 2019, at 11:59pm, Roman Fleysher
wrote:
> From experience, it seems that because SQLite still requests file locks, the
> performance increase is not that big. I wonder if there is a way to disable
> SQLite's internal file locking mechanism. I know this seems strange to ask.
> But
( somewhat related to Re: [sqlite] Safe to use SQLite over a sketchy network?)
Dear SQLiters,
I am using SQLite over GPFS distributed file system. I was told it honestly
implements file locking. I never experienced corruption. But it is slow in the
sense that when many jobs from many compute
I've been reading about the LIKE optimization[1]. One of the constraints on its
use is:
> if case_sensitive_like mode is enabled then the column must indexed using
> BINARY collating sequence, or if case_sensitive_like mode is disabled then
> the column must indexed using built-in NOCASE
Thank you for the recommendations and latest adjustment, both work to
resolve the issue.
On Fri, Sep 27, 2019 at 12:37 PM Richard Hipp wrote:
> On 9/27/19, Micah Moore wrote:
> > Hello,
> >
> > Attempting to use the Pre-release snapshot of SQLite 3.30.0 amalgamation
> in
> > a [Catalyst](
> >
On September 26, 2019 9:26:23 a.m. EDT, Daniel Odom wrote:
>I am just now getting around to learning Swift and XCode. I am having a
>
>problem with 'LIKE'. When I do this:
>
>let queryString = "select name, phone, street, city, state from phone
>where name like '%?%'"
As others have said, '?'
On 9/27/19, Micah Moore wrote:
> Hello,
>
> Attempting to use the Pre-release snapshot of SQLite 3.30.0 amalgamation in
> a [Catalyst](
> https://developer.apple.com/ipad-apps-for-mac/) based project -- targeting
> UIKit for macOS -- fails with the error "'gethostuuid' is unavailable: not
>
Hello,
Attempting to use the Pre-release snapshot of SQLite 3.30.0 amalgamation in
a [Catalyst](
https://developer.apple.com/ipad-apps-for-mac/) based project -- targeting
UIKit for macOS -- fails with the error "'gethostuuid' is unavailable: not
available on macCatalyst"
Adapting this
On 9/27/19, Eric Boudaillier wrote:
>
> I am experiencing incorrect query result with SQLite 3.25.2 and 3.28.
This problem was resolved by check-in
https://sqlite.org/src/info/74ef97bf51dd531a which was included in
release 3.29.0. The same fix is also found in on branch-3.28
You can build your pattern in Swift, and use a single parameter:
let queryString = "select name, phone, street, city, state from phone
where name like '?'"
let pattern = "%\(name)%"
if sqlite3_bind_text(stmt, 1, pattern, -1, SQLITE_TRANSIENT) !=
SQLITE_OK {do whatever}
For a more
Hi,
I am experiencing incorrect query result with SQLite 3.25.2 and 3.28.
The database and the queries have been reduced to the minimum, so they
are not really relevant, but demonstrates better where is the problem.
Also note that the result is correct using SQLite 3.15.2.
Using the following
>> My question is: is it possible to prevent checkpoints from completing
>> successfully when a snapshot is alive?
>
> That depends on what you mean by "alive"?
Sorry, I meant "not finalized by sqlite3_snapshot_free".
Your precise answer lifts any doubt: only transactions can prevent
checkpoints
On 9/26/19, Gwendal Roué wrote:
>
> My question is: is it possible to prevent checkpoints from completing
> successfully when a snapshot is alive?
>
That depends on what you mean by "alive"?
An sqlite3_snapshot_get() simply records some numbers in private
memory of the database connection that
On 9/26/19, Raitses, Alex wrote:
> Hello,
> I have noticed that security CVE
> (https://nvd.nist.gov/vuln/detail/CVE-2019-16168) has been submitted on
> SQLite. As far as I can see the patch was submitted to the trunk.
> Will CVE patch be included in the 3.30.0?
Yes.
21 matches
Mail list logo
