SQLite3 regression

Adatbázis: SQL, XML DB

Találtam egy hibát az SQLite3-ban. Illetve éppen az a (némiképp filozófiai) kérdés, hogy hibáról van-e szó, vagy egyszerűen ez a működése.

Mielőtt továbbmennénk, leszögezem, hogy nem vagyok érdekelt a kérdésben. Nincsenek SQLite3-ra alapozott alkalmazásaim. Az SQLite csak annyiban érdekel, hogy interfészeket írok különböző adatbázisokhoz: Oracle, Postgres, MySQL, DB2 mellett az SQLite-hoz is. Az SQLite lehetőségeit letapogató programjaim egyikével akadtam a jelenségre. Vettem magamnak a fáradságot egy bug report elkészítésére, megírtam a jelenséget demonstráló programot Rubyban (azért Rubyban, hogy mindenki könnyen tanulmányozhassa) és beküldtem az SQLite3 users mailing listre.

A kérdéses Ruby program:

http://comfirm.hu/pub/sqlite3-regression.rb

Érdekelnének a vélemények.

Várhatóan meg fognak jelenni olyan posztok, amikben tanácsokat kapok, hogyan tudom elkerülni azt a jelenséget, amit demonstrálni akarok. Ezért itt leírok néhány lehetőséget, amit érdemes kipróbálni. Egy részüket leírtam a ruby script alján levő kommentekben is:

1) Ha nincs bekapcsolva a WAL mód (write ahead log, 6. sor kikommentezve), a jelenség megmarad, tehát nem függ a WAL-tól.

2) Ha nincs létrehozva a "proba_nev" index (28. sor kikommentezve), a jelenség megszűnik.

3) Ha a select bármilyen módon rendezve van, azaz írunk egy _akármilyen_ plusz order by klózt az 54. sorba, a jelenség megszűnik.

4) Ha teljesen kihagyjuk az 56. sorban levő update-et, a jelenség megszűnik.

5) Ha úgy módosítjuk, az 56. sorban levő update-et, hogy ne módosítsa a "megnevezes" mezőt, a jelenség megszűnik.

6) Ha az sqlite3 könyvtár mostani változatai helyett a 3.7.9 verzióval futtatjuk a programot, a jelenség megszűnik.

Még biztos lehetnek további ötletek is. Nem érdekelnek az olyan megjegyzések, hogy a design pattern jó vagy rossz. Ezek legális SQL utasítások, amiket az adatbázisnak így vagy úgy végre kell hajtania. A kérdés az, hogy amit az SQLite3 csinál, az hiba-e. Az bizonyos hogy _regresszió_ (vagyis magyar szóval _eltérés_), hiszen látjuk, hogy a 3.7.9 még másképp működik, mint a későbbiek.

  • 1374 megtekintés

( haspokember | 2017. 03. 10., p – 11:42 )

Szerintem egyertelmuen hiba, tavolrol ugy tunik (nem ismerem a SQLite kodjat), hogy az index valahogy nem teljesen resze a tranzakcios lognak. Az, hogy eddig mukodott, talan csak a veletlen muve.

Ez egy jo osszefoglalo a listarol (http://www.mail-archive.com/sqlite-users%40mailinglists.sqlite.org/msg1…):

"1. Your row-by-row update is not a good design choice.

2. And it doesn't work correctly in SQLite, by design.

3. SQLite fails to keep its ACID promise: SELECT is not atomic, and
not isolated from UPDATE.

The ACID fault is a recurring theme on this list. You are not
the first person bitten by it, and won't be the last."

Gondolom ez egy kompromisszum a kod egyszerusege, sebessege es korrektsege kozott. Mondjuk a dokumentacioban nem talaltam errol semmifele leirast. Talan ez a nagyobb problema.

ui: mellekszal, de szorakoztato volt az angol nyelvu levlistan a magyar oszlopneveket idezve latni a nemzetkozi kozonsegtol, illetve hogy a magyar nyelvu levelezo beallitasod miatt a vezetekneveden lettel megszolitva :)

Köszönöm, ez így megnyugtató. A levlistáról gyorsan leiratkoztam, mert féltem, hogy agykárosodást kapok. Nem az SQLite hibája miatt, hanem az értetlenségtől, meg hogy minduntalan azt akarták magyarázni, hogyan javítsam ki a programomat. Nincs semmilyen programom, amit ki kellene javítani.

Egyébként gondoltam, hogy feature lesz, mint ahogy eleve a poszt címe is mutatja. Nyilván muszáj neki featurenek lenni, mert hibának túl durva volna.

De pl. ez a fickó, akit belinkeltél, ő is azt állítja, hogy a "feature" a WAL módtól függ. Holott a scriptemben egyetlen sor kikommentezésével meggyőződhetett volna arról, hogy nem függ a WAL-tól. WAL-lal, vagy anélkül egyformán rossz. Szóval ez már fájt, hogy minden hülyeséget válaszolgatnak, de lusták bármit is kipróbálni.
--
ulysses.co.hu

Az SQL tankönyvekből (persze más a tankönyv és más az élet) úgy tanultuk, hogy az SQL egyik alapelve, hogy az indexek léte/nemléte nem befolyásolja a queryk eredményét. Például a select-ből kapott sorok (a sorrendjüktől eltekintve) nem függhetnek attól, hogy milyen indexek léteznek.

A jelenleg tárgyalt példa mutatja, hogy milyen zagyvaságra lehet számítani, ha az ilyen alapelvek sérülnek. Tegyük fel, hogy egy program úgy kezdi a pályafutását, hogy nincs benne a "proba_nev" index. A program prímán működik, az alkotó gyanútlan. Egyszer csak azonban valakinek eszébe jut, hogy optimalizálás céljából a táblát ellátja egy plusz indexszel. És nézd csak, a jónak gondolt program egyszerre elkezd hibázni.

--
ulysses.co.hu

Az, hogy eddig mukodott, talan csak a veletlen muve.

Erre még külön is válaszolok: Nem gondolom, hogy a véletlen műve volt. Általában, ha valami jó, az a legritkább esetben lehet véletlen. A rossz dolgok sokkal inkább múlnak a véletlenen. Ha például egy művész jól eljátszik egy hegedűversenyt az nem lehet véletlen, hanem baromi sokat gyakorolt. Ha viszont elrontja, az lehet azért, mert éppen dekoncentrált, beteg, vagy akármi.
--
ulysses.co.hu

Még egyszer a belinkelt posztról:

"As has been repeated several times in this thread, the act of updating
a SQLite database while a SELECT is being processed interferes with the
SELECT unless WAL mode is used."

unless

Jelenti-e ez azt, hogy viszont amikor be van állítva a WAL mód, akkor az update nem interferál a selecttel? Egyébként, ha megnézte volna a scriptemet, láthatta volna, hogy WAL mód van beállítva.

Ezennel kijelentem, hogy elengedem a témát. Semmi közöm az SQLitehoz. Mint említettem, én csak egy interfész író vagyok, az kész van, mással nincs dolgom.
--
ulysses.co.hu

( vl v | 2017. 03. 10., p – 13:52 )

Ezek legális SQL utasítások, amiket az adatbázis így vagy úgy végrehajt.
A levlistán elhangzottak szerint a konkrét eset ún. nemspecifikált működés, aminek az egyik következménye, hogy bármi lesz a végeredmény, az megfelel az elvárásoknak (= nincsenek elvárások), ergó nem tekintjük hibának. Emiatt viszont regresszióról sincs értelme beszélni, mert az csak a helyes működés elmúlása esetén jöhet szóba - de mivel erre sosem mondta senki, hogy hogyan kellene neki működnie, így nincs minek elmúlnia.

Az sqlite egy lebutított, leegyszerűsített adatbázis, ami bizonyos dolgokat jól megcsinál, ha mást szeretnél, akkor viszont nem ezt kell használni.

( mrev | 2017. 03. 10., p – 21:05 )

Azt azért még leírom, mi az, amire eddig csak mint "jelenségre" hivatkoztam: Egy 10 sort adó select bizonyos körülmények között végtelen ciklussá változik. Azért nem írtam ki elsőre, hogy akik lusták lefuttatni a scriptemet, ne kotyogjanak közbe.
--
ulysses.co.hu