Hello,
I have a big json string in an sqlite memory database.
The json string contains also arrays like:
"arrayname" : [
{
"name" : "unique_name",
"id" : 1,
...
},
..
]
Currently I create my own index on "name" and "id" and get the values with:
json_extract(db.json,'$.arraynam
On 26/03/18 13:30, Simone Mosciatti wrote:
> However I fail to see how this can be a problem for purely in-memory
> database.
When a process forks, only the thread that called fork is kept in the
new child process. Also note that semaphores (and locks in general) are
left in the same state as at
Simone Mosciatti wrote:
> it is suggested in several place to don't share a connection between forks.
Because of how locking and file handles interact.
> However I fail to see how this can be a problem for purely in-memory database.
In-memory databases do not use a file handle or file locking.
Hi all,
it is suggested in several place to don't share a connection between forks.
However I fail to see how this can be a problem for purely in-memory
database.
If my understanding of fork and sqlite are correct I don't see issues in
having a forked child reading a database connection open
24 mrt 2018, Wout Mertens:
...
SELECT "id" AS _1,"json" AS _2 FROM "testing"
WHERE json_extract(json, '$.foo') < 50
ORDER BY json_extract(json, '$.foo') DESC,"id"
...
SELECT _1, _2 FROM (
SELECT "id" AS _1,"json" AS _2, json_extract(json, '$.foo') AS _3 FROM
"testing"
WHERE _3 < 50
ORDER BY _3
On 26 Mar 2018, at 9:26am, Olivier Mascia wrote:
> Simon, if this discussion is really around the branch
> 'server-process-edition', it was my (possibly wrong) understanding that this
> is not really true. This branch does apply page-level locking, or I got it
> all wrong.
Whoops. Thanks for
> Le 26 mars 2018 à 10:20, Simon Slavin a écrit :
>
> On 26 Mar 2018, at 8:57am, Marco Bambini wrote:
>
>> So it has nothing to do with which table/row the transaction is modifying?
>
> Correct. SQLite does not have table-locking or row-locking. Any locks in a
> SQLite database lock the ent
On 26 Mar 2018, at 8:57am, Marco Bambini wrote:
> So it has nothing to do with which table/row the transaction is modifying?
Correct. SQLite does not have table-locking or row-locking. Any locks in a
SQLite database lock the entire database. This is a fundamental aspect of
SQLite and one of
Think of transactions as cars and the rows as the paving stones of a paved car
park, and writing data as parking your car. You cannot park two cars on the
same paving stones at the same time without creating a collision. The second
car will have to leave the car park and try again.
-Ursprün
So it has nothing to do with which table/row the transaction is modifying?
In your example connection 2 always returns with an error on COMMIT?
Seems like the improvement is only on when the error occurs and not on
concurrency or am I missing something?
--
Marco Bambini
http://www.sqlabs.com
http
On 26 Mar 2018, at 8:09am, Marco Bambini wrote:
> Is there a better formal description about the "transactions may not overlap"
> sentence?
> Is there any example about overlapping transactions?
Overlapping transactions occur when a second connection does a BEGIN before the
first connection do
Is there a better formal description about the "transactions may not overlap"
sentence?
Is there any example about overlapping transactions?
--
Marco Bambini
http://www.sqlabs.com
http://twitter.com/sqlabs
>> The begin-concurrent branch
>> (https://sqlite.org/src/timeline?r=begin-concurrent&n=
12 matches
Mail list logo