» »

Nova različica podatkovne baze PostgreSQL 9.5 prinaša obilico novosti

1
2
»

trstenjak ::

'When a commit statement is executed, all constraints are effectively checked'

Dokumentacija govori o commitu na koncu več zaporednih ukazov, mi pa smo diskutirali o situaciji, ko že znotraj transakcije več ne moreš izvajati ukazov. Primer, ko bi še nekdo drug v času tvoje transakcije dodal zapis s enakim enoličnim ključem in ga commital pred tabo. Ti commitaš, logično sledi napaka pri tebi, da se tvoja transakcija v celoti rollbacka. Nima pa to veze z Postgresql obnašanjem pri error handlingu.

McAjvar ::

Če dovolj selektivno bereš, potem res lahko govori le o tem. Prva poved v citatu definira, kaj naj se zgodi, če do kršitev omejitev pride pred zaključkom transakcije - lahko tudi že pri prvem insertu.

Če pride do napak pri preverjanju omejitev (preverjanje unikatnosti, null, ...), imaš dve možnosti: ali boš obveščen takoj ali pa najkasneje pri commitu, odvisno od omejitve (immediate ali deferred constraint). V obeh primerih pa se transakcija ne bi smela uspešno zavesti.

If any constraint is not satisfied, then any changes to SQL-
data or schemas that were made by the current SQL-transaction
are canceled and an exception condition is raised: transac-
tion rollback-integrity constraint violation.


Oracle ti sporoči, da je prišlo do napake. Na tebi je potem, če se odločiš to ignorirat. Postgres te recimo, če se ne motim, od prve napake dalje obvešča, da zaradi pojava le-te ne bo več izvajal nadaljnjih ukazov, kar si glede na specifikacijo očitno lahko privošči.
"[...] the advance of civilization is nothing
but an exercise in the limiting of privacy."
- Isaac Asimov

MrStein ::

"When a constraint is checked other than at the end of an SQL-
transaction, if it is not satisfied, then an exception condition
is raised and the SQL-statement that caused the constraint to be
checked has no effect other than entering the exception information
into the diagnostics area. "

Tega se Oracle drži.

"When a <commit statement> is executed,
all constraints are effectively checked and, if any constraint
is not satisfied, then an exception condition is raised and the
transaction is terminated by an implicit <rollback statement>."

Tega tudi.

Kdor ima dvome, lahko sam proba, download je zastonj.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Jst ::

Saj tako delajo vse SQL baze; kako bi pa drugače zagotovil pristnost/unikatnost podatkov?

---

Kar se pa tiče error handlinga. Najbolje se je pred začetkom projekta zmeniti, kako se bo error/exception handling* izvajal in potem vsi tako delajo. Tako je debug neke kode, ki jo je napisal kdo drug, precej lažje.

*Pa ne samo za error/exception handling podatkov za v bazo, ampak več stvari, da je koda čimbolj standardna/podobna med različnimi programerji.

Sicer pa, tudi Baze imajo raznorazne nastavitve in je dobro prebrati dokumentacijo (za pluse in minuse), nastaviti projektu primerno in stestirati z dummy podatki.
Islam is not about "I'm right, you're wrong," but "I'm right, you're dead!"
-Wole Soyinka, Literature Nobelist
|-|-|-|-|Proton decay is a tax on existence.|-|-|-|-|

McAjvar ::

MrStein je izjavil:

"When a <commit statement> is executed,
all constraints are effectively checked and, if any constraint
is not satisfied, then an exception condition is raised and the
transaction is terminated by an implicit <rollback statement>."

Tega tudi.


Zaradi odebeljenega in zlasti podčrtanega dela se ne strinjam. Oracle naredi rollback le za query, ki pade, ne pa za celotno transakcijo.

Edit: Sicer me zanima, kaj o transakcijah piše v aktualni verziji standarda. SQL-92 je namreč precej star in so ga vmes zamenjali že novejši, zadnji je SQL:2011. Med drugim recimo Wiki pravi, da se po standardu transakcijo začne s "START TRANSACTION", česar v SQL-92 nisem našel...
"[...] the advance of civilization is nothing
but an exercise in the limiting of privacy."
- Isaac Asimov

Zgodovina sprememb…

  • spremenil: McAjvar ()

MrStein ::

> Oracle naredi rollback le za query, ki pade, ne pa za celotno transakcijo.

Si preizkusil?
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

MrStein ::

Ker v dokumentaciji lepo piše:

Specify DEFERRABLE to indicate that in subsequent transactions you can use the SET
CONSTRAINT [ S ] clause to defer checking of this constraint until a COMMIT statement
is submitted. If the constraint check fails, then the database returns an error and
the transaction is not committed.


Za druge iz anusa potegnjene zaključke pa žal več ne bom imel časa odgovorjati. Prijeten slotek vam želim.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

McAjvar ::

Če bi rad kaj povedal, potem prosim izvoli. Kar me sprašuješ, si preizkusil tudi sam (menda).

Glede na zapisano v standardu, jaz pričakujem, da bi v primeru, ki si ga navedel, v bazi dejansko bila le ena vrstica, z id 22.

If the constraint check fails, then the database returns an error and
the transaction is not committed.


Zakaj potem tam ostane tudi tista z id 11? Transakcija zajema oba inserta. Tistega z 11 in tistega z null.

Lahko se obnašaš kot tepec, če želiš, lahko pa mi tudi pojasniš, zakaj "not committed" v resnici pomeni "partially committed".
"[...] the advance of civilization is nothing
but an exercise in the limiting of privacy."
- Isaac Asimov
1
2
»


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

MySQL ali kaj drugega?

Oddelek: Programiranje
102086 (1404)          
»

Nova različica podatkovne baze PostgreSQL 9.5 prinaša obilico novosti (strani: 1 2 )

Oddelek: Novice / Ostala programska oprema
5716283 (13149) McAjvar
»

Kombinacija relacijske/nerelacijske podatkovne baze

Oddelek: Programiranje
81846 (1453) AndrejO
»

Izšel je Drupal 7

Oddelek: Novice / Ostala programska oprema
167094 (5306) CvEtKo
»

mysql "hitrost"

Oddelek: Izdelava spletišč
91824 (1706) Veron

Več podobnih tem