Baza danych HTML5 - transakcja wywołań wywołania zwrotnego VS executeSql

Question

mówi o bazie danych HTML5 (sqlite), ostatnio używałem wywołań zwrotnych dotyczących powodzenia/błędu zarówno z funkcji transaction, jak i executeSql. I okazało się, że dla tych dwóch funkcji, sukces/error callback kolejność jest odwrotna, na przykład:

transakcji

database.transaction(function(tx){ 
    //--- do something 
}, function(){ 
    //--- error handling 
}, function(){ 
    //--- success handling 
}); 

ExecuteSQL

tx.executeSql(sqlStatement, [], successCallback, errorCallback); 

Prawdopodobnie to nie jest ważne o czym należy wiedzieć, ale chciałbym się dowiedzieć, czy istnieje powód takiego odwrotnego zamówienia .. IMHO, byłoby użyteczne mieć takie samo zamówienie oddzwonienia dla każdej funkcji, tak jak uczyłeś się jak go używać, wiesz, jak działają wszystkie inne!

Dzięki z góry, chodzi

Answer 1

Mam tu na myśli [the main RFC document]: a warto zauważyć, że

Ta specyfikacja nie jest już czynnie konserwacji i internecie Applications Grupa robocza nie zamierzam go dalej podtrzymywać.

Niemniej jednak wracamy do pytania. Rozumowanie za tym może być pochowane in the archives of the discussion mailing lists

Mogę uzasadnić, jak ludzie zwykle budują API.

Pierwszą rzeczą, na którą należy zwrócić uwagę, jest to, że różne argumenty wywołania zwrotnego obu funkcji są opcjonalne, więc chcesz je zamówić od najczęściej używanych do najmniej używanych. Jeśli umieścisz go w odwrotnej kolejności, zmuszasz ludzi do deklarowania pustych funkcji.

Transakcja sprawia, że ​​obsługa błędów jest ważniejsza niż obsługa sukcesów. Transakcje są "zaprojektowane" tak, by zawodzić z wdziękiem i niezwykle ważne, ponieważ oczekujemy, że od czasu do czasu zawiodą i poradzą sobie z ich awarią.

Wręcz przeciwnie, zapytanie powinno zwracać swoje wyniki, bez zbytniego niepowodzenia. Podczas gdy mamy powodzenie, a to powinno się zdarzyć naprawdę często, chcemy przetworzyć wynik takiego zapytania, i to jest, gdy używasz SQLStatementCallback callback, który nie jest SQLVoidCallback successCallback. To wywołanie zwrotne nie służy do obsługi sukcesu, ale do jawnego przetwarzania wyników instrukcji (tj. Do przetwarzania wyników).

Porównaj tutaj deklaracje transaction i executeSql.