> Actually, you do know what SQLite does without knowing the internals. It
> claims to be serializable and ACID
> (http://www.sqlite.org/transactional.html), therefore it's fine.

"Serializable" there means that once transaction is started statements
won't see any data committed in other transactions. But it doesn't
impose any restrictions on how statements should behave within the
same transaction. And in SQLite it's pretty unpredictable and so even
SQLite's documentation prohibits updating some table while select
statement on it is active (I can find a link on sqlite.org for you
when I have some spare time).


Pavel


On Wed, Jun 1, 2011 at 2:41 PM, Robert Myers <rob.my...@ziften.com> wrote:
> On 6/1/2011 1:23 PM, Simon Slavin wrote:
>> On 1 Jun 2011, at 7:12pm, Jan Hudec wrote:
>>
>>> On Wed, Jun 01, 2011 at 10:17:02 -0400, Pavel Ivanov wrote:
>>>>>  From within a BEGIN TRANSACTION and END TRANSACTION block, should I not
>>>>> update the same row in a table more than once?
>>>> You can update it as many times as you need.
>>>>
>>>>>  What are the exact limitations on what I can do during a Transaction?
>>>> Do not update a table if there is some select statement currently
>>> Actually insert, update and delete are OK. Drop and alter table are
>>> a problem.
>> Pavel is right.  He left out some details to make things simple.
>>
>> Suppose you do a SELECT ... WHERE ... that returns ten rows.  You retrieve 
>> three rows, then make a change that would mean you should have retrieved 
>> eleven rows, not ten.  You can't predict what SQLite will do without knowing 
>> the internal workings of SQLite, right ?  So don't do that.  The same is 
>> true even if the only thing you change is values to be returned.  Does 
>> SQLite copy the all values when you execute the SELECT, or row-by-row as you 
>> step through the results ?  Again, you don't know unless you know the 
>> internal workings of SQLite.  So don't do that.
>>
>> Simon.
>> _______________________________________________
>
> Actually, you do know what SQLite does without knowing the internals. It
> claims to be serializable and ACID
> (http://www.sqlite.org/transactional.html), therefore it's fine.
> _______________________________________________
> 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