[Webkit-unassigned] [Bug 28918] Add support for Database.readTransaction()
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Sep 3 22:21:34 PDT 2009
https://bugs.webkit.org/show_bug.cgi?id=28918
--- Comment #4 from Michael Nordman <michaeln at google.com> 2009-09-03 22:21:33 PDT ---
This looks pretty nice. So the method is available, and a flag is plumbed
throughout, and the authorizer enforces readonly'ness. I take it you're saving
allowing concurrent r/o transactions on the same db thread for a later patch?
http://www.sqlite.org/lang_reindex.html
It looks like REINDEX is a write operation, but I think its being allowed for
readOnly transactions... is this what you intended and why?
What does the HTML5 draft say about the behavior of a readOnly transaction when
a write operation is attempted? As coded, looks like the statement fails, but
the transaction is left open and other statements can be executed in that
transaction. Does that match the spec'd behavior? I can imagine another
behavior, the transaction fails and is closed when a write operation is
attempted... just checking.
7979 void transaction(PassRefPtr<SQLTransactionCallback> callback,
PassRefPtr<SQLTransactionErrorCallback> errorCallback,
80 PassRefPtr<VoidCallback> successCallback);
80 PassRefPtr<VoidCallback> successCallback, bool
readOnly = false);
Are there any callsites that don't explicitly pass a value for the readOnly
parameter? Consider removing the default param value.
BTW... have you seen the SAVEPOINT statement in newer versions of SQLite? Looks
like support in sqlite3 for transaction nesting. Wondering if that capability
should be reflected in the HTML5 api in some way?
http://www.sqlite.org/lang_savepoint.html
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list