> If you want to know which rows were updated regardless of the key, what
> you need is a column to hold a unique value for each update transaction,
> and set it as part of the UPDATE. You could add a datetime column,
> for example, if the time resolution is fine enough.
Good idea. I found
>> There is sqlite3_update_hook() function that returns rowid of changed record.
> sounds promising, but apparently not supported by the python wrapper.
Not the included sqlite3/pysqlite dbiapi wrapper -- though it is supported by
Roger Binns APSW wrapper.
http://code.google.com/p/apsw/
---
On Fri, Jan 25, 2013 at 1:36 AM, Yongil Jang wrote:
> There is sqlite3_update_hook() function that returns rowid of changed
> record.
sounds promising, but apparently not supported by the python wrapper.
___
sqlite-users mailing
On Thu, 24 Jan 2013 16:47:02 +1100
Richard Baron Penman wrote:
> How to find which keys have been updated from this query?
That's the problem with "limit N", right? It's not based on the data.
Not only do you not know which rows were updated, you don't know which
ones were
Penman wrote:
How to find which keys have been updated from this query?
There is sqlite3_update_hook() function that returns rowid of changed
record.
Regards,
Yongil Jang.
On Jan 24, 2013 11:10 PM, "Igor Tandetnik" wrote:
> On 1/24/2013 12:47 AM, Richard Baron Penman wrote:
On 1/24/2013 12:47 AM, Richard Baron Penman wrote:
How to find which keys have been updated from this query?
You can't, really. If you need a list of keys (or in fact a list of
anything from the database), you need to run a SELECT statement. At
which point you are back where you started and
> Why process only N at a time, Richard?
There are a number of workers who request unprocessed jobs from the queue.
But the queue is too big to hold in memory all at once.
___
sqlite-users mailing list
sqlite-users@sqlite.org
Thanks for tip about the redundant index.
How to find which keys have been updated from this query?
On Thu, Jan 24, 2013 at 3:32 PM, Keith Medcalf wrote:
>> I have a table like this:
>>
>> CREATE TABLE queue (
>> key TEXT NOT NULL PRIMARY KEY UNIQUE,
>> status
On Wed, 23 Jan 2013 21:32:20 -0700
"Keith Medcalf" wrote:
> > And then I process it like this, N keys at a time:
> >
> > SELECT key FROM queue WHERE status=0 LIMIT N;
> > BEGIN TRANSACTION;
> > for key in keys:
> > UPDATE queue SET status=1 WHERE key=key;
> > END
On 1/23/2013 11:22 PM, Richard Baron Penman wrote:
And then I process it like this, N keys at a time:
SELECT key FROM queue WHERE status=0 LIMIT N;
BEGIN TRANSACTION;
for key in keys:
UPDATE queue SET status=1 WHERE key=key;
END TRANSACTION;
How can this SELECT and UPDATE be combined
> I have a table like this:
>
> CREATE TABLE queue (
> key TEXT NOT NULL PRIMARY KEY UNIQUE,
> status INTEGER
> );
> CREATE INDEX IF NOT EXISTS keys ON queue (key);
Your index is redundant. There is already a unique index on key since it is a
primary key.
It should probably be:
11 matches
Mail list logo