Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(685)

Unified Diff: third_party/WebKit/Source/modules/webdatabase/SQLStatementBackend.cpp

Issue 2395473002: reflow comments in modules/webdatabase (Closed)
Patch Set: Created 4 years, 2 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
Index: third_party/WebKit/Source/modules/webdatabase/SQLStatementBackend.cpp
diff --git a/third_party/WebKit/Source/modules/webdatabase/SQLStatementBackend.cpp b/third_party/WebKit/Source/modules/webdatabase/SQLStatementBackend.cpp
index 7d51a00984f736ccdf142cfe99d0b94c67870b10..d67754efb88ab67cf03fc758c4441f94e0917765 100644
--- a/third_party/WebKit/Source/modules/webdatabase/SQLStatementBackend.cpp
+++ b/third_party/WebKit/Source/modules/webdatabase/SQLStatementBackend.cpp
@@ -42,31 +42,43 @@
//
// At birth (in SQLTransactionBackend::executeSQL()):
// =================================================
-// SQLTransactionBackend // HeapDeque<Member<SQLStatementBackend>> m_statementQueue points to ...
-// --> SQLStatementBackend // Member<SQLStatement> m_frontend points to ...
-// --> SQLStatement
+// SQLTransactionBackend
+// // HeapDeque<Member<SQLStatementBackend>> m_statementQueue
+// // points to ...
+// --> SQLStatementBackend
+// // Member<SQLStatement> m_frontend points to ...
+// --> SQLStatement
//
-// After grabbing the statement for execution (in SQLTransactionBackend::getNextStatement()):
-// =========================================================================================
-// SQLTransactionBackend // Member<SQLStatementBackend> m_currentStatementBackend points to ...
-// --> SQLStatementBackend // Member<SQLStatement> m_frontend points to ...
-// --> SQLStatement
+// After grabbing the statement for execution (in
+// SQLTransactionBackend::getNextStatement()):
+// ======================================================================
+// SQLTransactionBackend
+// // Member<SQLStatementBackend> m_currentStatementBackend
+// // points to ...
+// --> SQLStatementBackend
+// // Member<SQLStatement> m_frontend points to ...
+// --> SQLStatement
//
-// Then we execute the statement in SQLTransactionBackend::runCurrentStatementAndGetNextState().
-// And we callback to the script in SQLTransaction::deliverStatementCallback() if
-// necessary.
-// - Inside SQLTransaction::deliverStatementCallback(), we operate on a raw SQLStatement*.
-// This pointer is valid because it is owned by SQLTransactionBackend's
+// Then we execute the statement in
+// SQLTransactionBackend::runCurrentStatementAndGetNextState().
+// And we callback to the script in
+// SQLTransaction::deliverStatementCallback() if necessary.
+// - Inside SQLTransaction::deliverStatementCallback(), we operate on a raw
+// SQLStatement*. This pointer is valid because it is owned by
+// SQLTransactionBackend's
// SQLTransactionBackend::m_currentStatementBackend.
//
-// After we're done executing the statement (in SQLTransactionBackend::getNextStatement()):
-// =======================================================================================
+// After we're done executing the statement (in
+// SQLTransactionBackend::getNextStatement()):
+// ======================================================================
// When we're done executing, we'll grab the next statement. But before we
-// do that, getNextStatement() nullify SQLTransactionBackend::m_currentStatementBackend.
-// This will trigger the deletion of the SQLStatementBackend and SQLStatement.
+// do that, getNextStatement() nullify
+// SQLTransactionBackend::m_currentStatementBackend.
+// This will trigger the deletion of the SQLStatementBackend and
+// SQLStatement.
//
-// Note: unlike with SQLTransaction, there is no JS representation of SQLStatement.
-// Hence, there is no GC dependency at play here.
+// Note: unlike with SQLTransaction, there is no JS representation of
+// SQLStatement. Hence, there is no GC dependency at play here.
namespace blink {
@@ -114,11 +126,12 @@ SQLResultSet* SQLStatementBackend::sqlResultSet() const {
bool SQLStatementBackend::execute(Database* db) {
ASSERT(!m_resultSet->isValid());
- // If we're re-running this statement after a quota violation, we need to clear that error now
+ // If we're re-running this statement after a quota violation, we need to
+ // clear that error now
clearFailureDueToQuota();
- // This transaction might have been marked bad while it was being set up on the main thread,
- // so if there is still an error, return false.
+ // This transaction might have been marked bad while it was being set up on
+ // the main thread, so if there is still an error, return false.
if (m_error)
return false;
@@ -145,8 +158,9 @@ bool SQLStatementBackend::execute(Database* db) {
return false;
}
- // FIXME: If the statement uses the ?### syntax supported by sqlite, the bind parameter count is very likely off from the number of question marks.
- // If this is the case, they might be trying to do something fishy or malicious
+ // FIXME: If the statement uses the ?### syntax supported by sqlite, the bind
+ // parameter count is very likely off from the number of question marks. If
+ // this is the case, they might be trying to do something fishy or malicious
if (statement.bindParameterCount() != m_arguments.size()) {
STORAGE_DVLOG(1)
<< "Bind parameter count doesn't match number of question marks";
@@ -203,7 +217,8 @@ bool SQLStatementBackend::execute(Database* db) {
if (db->lastActionWasInsert())
m_resultSet->setInsertId(database->lastInsertRowID());
} else if (result == SQLResultFull) {
- // Return the Quota error - the delegate will be asked for more space and this statement might be re-run
+ // Return the Quota error - the delegate will be asked for more space and
+ // this statement might be re-run.
setFailureDueToQuota(db);
return false;
} else if (result == SQLResultConstraint) {
@@ -221,9 +236,10 @@ bool SQLStatementBackend::execute(Database* db) {
return false;
}
- // FIXME: If the spec allows triggers, and we want to be "accurate" in a different way, we'd use
- // sqlite3_total_changes() here instead of sqlite3_changed, because that includes rows modified from within a trigger
- // For now, this seems sufficient
+ // FIXME: If the spec allows triggers, and we want to be "accurate" in a
+ // different way, we'd use sqlite3_total_changes() here instead of
+ // sqlite3_changed, because that includes rows modified from within a trigger.
+ // For now, this seems sufficient.
m_resultSet->setRowsAffected(database->lastChanges());
db->reportExecuteStatementResult(0, -1, 0); // OK

Powered by Google App Engine
This is Rietveld 408576698