rilevante

Non so se vi e' mai capitato ma segnalo
strano comportamento.

Setto autocommit a false, quindi faccio
cose tipo:

connection.execute('INSERT bla bla bla');
connection.execute('UPDATE bla bla bla');

poi ad un certo punto devo spegnere dei
triggers:

connection.execute('ALTER TABLE pippo DISABLE ALL TRIGGERS');

Oh, se per qualche motivo faccio rollback,
ebbene... e' gia' tutto commitato, anche se
autocommit e' false.

In pratica quell'alter table, non so perche',
e' come se mettesse a true l'autocommit.

Buffo.

il 20.02.2012 16:42, Scrive youarethetruthnoti 113775776:
[..]
> connection.execute('ALTER TABLE pippo DISABLE ALL TRIGGERS');
>
> Oh, se per qualche motivo faccio rollback,
> ebbene... e' gia' tutto commitato, anche se
> autocommit e' false.
>
> In pratica quell'alter table, non so perche',
> e' come se mettesse a true l'autocommit.
>
> Buffo.
Non tutti gli statement sql sono committabili, eventualmente fai
riferimento alla documentazione del DB.

Dr.Ugo Gagliardelli ha scritto:

> Non tutti gli statement sql sono committabili, eventualmente fai
> riferimento alla documentazione del DB.

Si, tuttavia la cosa che mi colpisce e' che gli
statement (nel veloce esempio fornito) dati nella
connection con autocommit = false non subiscono
il rollback! Quindi il problema non e' la non
committabilita', ma l'opposto: si committano
da se' nonostante l'esplicitazione di non farlo!

Grazie

il 20.02.2012 19:03, Scrive youarethetruthnoti 113775776:
> Dr.Ugo Gagliardelli ha scritto:
>
>> Non tutti gli statement sql sono committabili, eventualmente fai
>> riferimento alla documentazione del DB.
>
> Si, tuttavia la cosa che mi colpisce e' che gli
> statement (nel veloce esempio fornito) dati nella
> connection con autocommit = false non subiscono
> il rollback! Quindi il problema non e' la non
> committabilita', ma l'opposto: si committano
> da se' nonostante l'esplicitazione di non farlo!

Mi sono espresso male.
Intendevo dire che alcuni statement non possono far parte di una
unit-of-work, quindi di una transazione, per cui non possono essere
assoggettati ne' a commit ne' a rollback.
Da cui l'effetto "buffo" simile all'autocommit, in realta' vengono
eseguiti e basta, per tornare indietro e' necessario eseguire
l'operazione opposta, sempre che esista.
Prendi ad esempio una CALL ad una stored procedure che fa un calcolo e
restituisce un valore, magari in modo non deterministico, come faresti a
farne il roll-back?

Il 20/02/2012 19:17, Dr.Ugo Gagliardelli ha scritto:
> il 20.02.2012 19:03, Scrive youarethetruthnoti 113775776:
>
> Mi sono espresso male.
> Intendevo dire che alcuni statement non possono far parte di una
> unit-of-work, quindi di una transazione, per cui non possono essere
> assoggettati ne' a commit ne' a rollback.
> Da cui l'effetto "buffo" simile all'autocommit, in realta' vengono
> eseguiti e basta, per tornare indietro e' necessario eseguire
> l'operazione opposta, sempre che esista.
> Prendi ad esempio una CALL ad una stored procedure che fa un calcolo e
> restituisce un valore, magari in modo non deterministico, come faresti a
> farne il roll-back?

Non ho capito neppure io cosa stai dicendo. Se una SP fa un calcolo non
c'è nulla di cui fare rollback o commit, ma se scrive su db si. Non si
capisce perche' uno dovrebbe aspettarsi un commit di una procedura che
non ha effetto sulla base dati.

Per il probblema del OP, è possibile che qualche trigger stia
effettuando un commit. Controlla tutti i trigger e SP invocate.

il 20.02.2012 20:41, Scrive cicap 113775776:
> Il 20/02/2012 19:17, Dr.Ugo Gagliardelli ha scritto:
[...]
> Non ho capito neppure io cosa stai dicendo. Se una SP fa un calcolo non
> c'è nulla di cui fare rollback o commit, ma se scrive su db si. Non si
> capisce perche' uno dovrebbe aspettarsi un commit di una procedura che
> non ha effetto sulla base dati.
E' quello che sto dicendo, perche' dovrebbe aspettarsi di fare rollback
per lo statement alter table disable all triggers?

On 20 Feb, 16:42, thisDead...@TOGLIMIgMail.com (youarethetruthnoti)
wrote:

> connection.execute('ALTER TABLE pippo DISABLE ALL TRIGGERS');
>
> Oh, se per qualche motivo faccio rollback,
> ebbene... e' gia' tutto commitato, anche se
> autocommit e' false.

eh lo fanno, lo fanno... (cit.)
http://dev.mysql.com/doc/refman/5.0/...it-commit.html
"Statements That Cause an Implicit Commit" (alter table, create index,
drop index, etc...)
http://docs.oracle.com/cd/B19306_01/...htm#sthref3207
"Oracle Database implicitly commits the current transaction before and
after every DDL statement."

youarethetruthnoti wrote:

> Buffo.

Quello da te lanciato non e` un DML, ma un DDL che, nella quasi totalita`
dei database, e` una tipologia di comandi autocommittante. Quindi, il
comportamento da te riscontrato non e` buffo, ma corretto

Enrico

Enrico 'Henryx' Bianchi ha scritto:


> Quello da te lanciato non e` un DML, ma un DDL che, nella quasi totalita`
> dei database, e` una tipologia di comandi autocommittante. Quindi, il
> comportamento da te riscontrato non e` buffo, ma corretto

Vero, ma dovrebbe esserlo della sola,
o delle sole, DDL.

Il punto e' che se eseguo delle DML e dell
DDL sulla stessa connessione succede che
*tutte* le DML sono committate!

<g>

Dr.Ugo Gagliardelli ha scritto:

> E' quello che sto dicendo, perche' dovrebbe aspettarsi di fare rollback
> per lo statement alter table disable all triggers?

Infatti, spero di spiegarmi meglio:

Uso una connessione, gli metto autocommit a false.
Su questa connessione eseguo delle DML *e* delle
DDL. Se per qualche motivo devo fare il rollback
delle DML, beh e' inutile farlo perche' l'uso di
anche solo una DML ha committato *tutto*, anche
le DML. Rootkit ha gentilmente riportato la documentazione
del fenomeno.

Grazie

ops

errata

> (...) perche' l'uso di anche solo una DML

corrige

rootkit ha scritto:

> eh lo fanno, lo fanno... (cit.)

Anvedi.

Grazie!

Dr.Ugo Gagliardelli ha scritto:

> Mi sono espresso male.
> Intendevo dire che alcuni statement non possono far parte di una
> unit-of-work, quindi di una transazione, per cui non possono essere
> assoggettati ne' a commit ne' a rollback.
> Da cui l'effetto "buffo" simile all'autocommit, in realta' vengono
> eseguiti e basta, per tornare indietro e' necessario eseguire
> l'operazione opposta, sempre che esista.
> Prendi ad esempio una CALL ad una stored procedure che fa un calcolo e
> restituisce un valore, magari in modo non deterministico, come faresti a
> farne il roll-back?

Hai perfettamente ragione, sono io che mi sono
espresso confusamente.

Non voglio fare il rollback di statement che non
possono avere il rollback.

Per fartela brevissima: ho fatto una classe dove
esegue in sequenza degli statement, in pratica e'
un "esecutore" di script sql.

Tra questi ci sono le classiche operazioni DML e
delle DDL "ALTER TABLE" (per spegnere ed accendere
triggers).

Tutti gli statement vengono eseguiti attraverso la
stessa connessione con setAutoCommitt(false).

Ora, se per qualche motivo uno statement DML
fallisce la classe fa il rollback di tutto.

Tuttavia il rollback non ha alcun effetto perche'
tutte le DML sono state implicitamente committate
dall'uso di anche un solo statement DDL(!)

Invece, eseguendo gli statement DDL su un'altra
connessione, l'unita' transazionale degli statement
DML funziona.

Grazie

On 21 Feb, 09:04, thisDead...@TOGLIMIgMail.com (youarethetruthnoti)
wrote:

> > Quello da te lanciato non e` un DML, ma un DDL che, nella quasi totalita`
> > dei database, e` una tipologia di comandi autocommittante. Quindi, il
> > comportamento da te riscontrato non e` buffo, ma corretto
>
> Vero, ma dovrebbe esserlo della sola,
> o delle sole, DDL.

non ha senso quello che dici. la commit si riferisce alla transazione
in cui viene eseguito il comando e non al singolo comando.
in ogni caso è intuitivo che mischiare istruzioni transazionali e
istruzioni che alterano la struttura del db nella stessa transazione
porti a situazioni poco controllabili.

rootkit ha scritto:

> non ha senso quello che dici.

Penso invece che lo abbia.

> la commit si riferisce alla transazione
> in cui viene eseguito il comando e non al singolo comando.

Appunto, quello che mi aspettavo e'
proprio il commit o il rollback di
cio' che e' avvenuto, e che possa
avere "commit" o "rollback, nella
transazione.

> in ogni caso è intuitivo che mischiare istruzioni transazionali e
> istruzioni che alterano la struttura del db nella stessa transazione
> porti a situazioni poco controllabili.

Questo e' il punto: non ho intuito che
sulla stessa connessione un'istruzione
"non transazionale" influenza quelle
"transazionali".

Grazie