Yes, but I always insert with null:

        self.s.statement(
            "create temporary table undoLog (seq integer primary key,
sql text)")

after insert on %(t)s begin
insert into undoLog values
(null, ...)

after update on %(t)s begin
insert into undoLog values (null, 'update %(t)s ..

etc


On Fri, Mar 20, 2009 at 8:16 PM, Dan <danielk1...@gmail.com> wrote:
>
> Does the "undolog" table, or whatever you're using in its place, have
> a primary key?
>
> On Mar 20, 2009, at 1:20 PM, Damien Elmes wrote:
>
>> Well, those 3 x the number of tables in the Db.
>>
>> On Fri, Mar 20, 2009 at 3:17 PM, Damien Elmes <reso...@ichi2.net>
>> wrote:
>>> Yep - but only the three listed on this page:
>>>
>>> http://www.sqlite.org/cvstrac/wiki?p=UndoRedo
>>>
>>> So they shouldn't be modifying anything in the main DB, only the
>>> temporary DB.
>>>
>>> On Fri, Mar 20, 2009 at 3:13 PM, Dan <danielk1...@gmail.com> wrote:
>>>>
>>>> On Mar 20, 2009, at 8:10 AM, Damien Elmes wrote:
>>>>
>>>>> Unfortunately, a user has just reported the same primary key error
>>>>> message with shared cache disabled, although the freezing appears
>>>>> to
>>>>> have been fixed.
>>>>>
>>>>> However, when I ask the user to send me their deck, I find that:
>>>>>
>>>>> sqlite> pragma integrity_check;
>>>>> integrity_check
>>>>> ---------------
>>>>> ok
>>>>> sqlite> select id, count(id) from cards group by id having
>>>>> count(id)
>>>>>> 1;
>>>>> sqlite>
>>>>>
>>>>> Any ideas?
>>>>
>>>> Triggers?
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 20, 2009 at 10:00 AM, Damien Elmes <reso...@ichi2.net>
>>>>> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Some of my users have been reporting strange database problems
>>>>>> recently, which seem to have gone away when I removed a call to
>>>>>> enable_shared_cache(). The problems were noticeable in at least
>>>>>> 3.6.1
>>>>>> and 3.6.11, when using databases of 30MB+, and doing large updates
>>>>>> using pysqlite.
>>>>>>
>>>>>> There were two distinct reported problems. One was that the
>>>>>> program
>>>>>> would just freeze, with no disk access and CPU usage, seemingly in
>>>>>> the
>>>>>> middle of a DB query, on Win32. I wasn't able to reproduce this on
>>>>>> Linux.
>>>>>>
>>>>>> The other problem was reported by both win32 and mac users, and
>>>>>> again
>>>>>> I wasn't able to reproduce it. It resulted in errors like this:
>>>>>>
>>>>>> sqlalchemy.exceptions.IntegrityError: (IntegrityError) PRIMARY KEY
>>>>>> must be unique 'update cards set isDue = 0 where type in (0,1,2)
>>>>>> and
>>>>>> priority = 0 and isDue = 1' {}
>>>>>>
>>>>>> .. which is strange, because the primary key on that table is
>>>>>> called
>>>>>> 'id' and is not affected by the update call.
>>>>>>
>>>>>> I also had some reports of DB corruption on OSX, but I'm not
>>>>>> sure if
>>>>>> that occurred since I upgrade to 3.6.11.
>>>>>>
>>>>>> One other hint is that while I'd been using shared cache mode
>>>>>> for at
>>>>>> least 6 months or more, these problems seem to have only surfaced
>>>>>> recently. I'm not sure if that's due to a change in the queries
>>>>>> I've
>>>>>> been doing, or the fact that I changed the cache size to a bigger
>>>>>> number, and changed the page size to 4096.
>>>>>>
>>>>>> Anyway, disabling the shared cache appears to have fixed the
>>>>>> problem,
>>>>>> and since my program is single threaded and has no need for the
>>>>>> shared
>>>>>> cache, it's not an issue for us anymore. But I thought it's worth
>>>>>> reporting. Have there been any other instances of problems with
>>>>>> the
>>>>>> shared cache mode?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Damien
>>>>>>
>>>>> _______________________________________________
>>>>> sqlite-users mailing list
>>>>> sqlite-users@sqlite.org
>>>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>>>
>>>> _______________________________________________
>>>> sqlite-users mailing list
>>>> sqlite-users@sqlite.org
>>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>>>
>>>
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to