Questa non vi e' ancora capitata

O almeno lo spero per voi.

Debian-testing (etch), ruby 1.8.5, libmysqlclient15

faccio la select di un record e stampo il valore di un campo TINYINT:

x = db.select_one(…)
puts x[‘CAMPO’].inspect

=> “0”

Ooops… qualcosa non va.

Fra le innumerevoli prove, mi “scappa” questa:

xx = db.select_one(…)
puts xx[‘CAMPO’].inspect

=> 0

Ok, c’e’ qualcosa che non va.
Intanto che io mi rompo la testa per cercare il colpevole (sospetto
fortemente il compilatore gcc), qualcuno
ha una vaga idea di come CASPITA sia possibile?

E… usando altre lettere? Che risultati ottieni?


David N. Welton

Linux, Open Source Consulting

On Jan 30, 2007, at 9:37 PM, David W. wrote:

E… usando altre lettere? Che risultati ottieni?

Non ho provato proprio TUTTO l’alfabeto, ma sono abbastanza sicuro
che non dipenda dalle lettere :slight_smile:
Ma sono riuscito anche a produrre risultati piu’ inquietanti… per
esempio:

1| puts a[‘TEST’].inspect
2| puts b.test.inspect
3| puts b[‘TEST’].inspect

dove a e’ un record selezionato direttamente con DBI, b e’ lo stesso
record selezionato
usando un micro-wrapper che mi sono fatto per avere un minimo di
astrazione delle query (alla fine usa
comunque DBI) e il metodo “test” di b viene da un mixin ed e’
definito come:

def test; self[‘TEST’]; end

Sia row1 che row2 sono Hash.

Bene… al primo giro ottengo:

“0”
“0”
“0”

pero’ se COMMENTO la riga 2:

0
0

Purtroppo non ho tempo di fare altri test, questa cosa mi ha gia’
fatto perdere una giornata di lavoro
e devo mettere in produzione un server (ovviamente con ruby-1.8.4
compilato a manina).

On Jan 30, 2007, at 4:18 PM, Stefano C. wrote:

Le versioni:
server mysql 4.0.27
client mysql 4.1 compilato a mano dai sorgenti di mysql.com
ruby 1.8.5 (2006-08-25) [i486-linux]
ruby-dbi 0.1.1
mysql-ruby 2.7.3
rubygems 0.9.0

Updeit: dopo aver provato anche con l’ultima stable di ruby-1.8.5
(patchlevel 12) e aver verificato che il problema
rimane, ho sovrascritto l’installazione con la 1.8.4 ed e’ sparito.
Adesso provo con l’ultimo stable snapshot della 1.8.5…

On Jan 30, 2007, at 5:04 PM, Stefano C. wrote:

Updeit: dopo aver provato anche con l’ultima stable di ruby-1.8.5
(patchlevel 12) e aver verificato che il problema
rimane, ho sovrascritto l’installazione con la 1.8.4 ed e’ sparito.
Adesso provo con l’ultimo stable snapshot della 1.8.5…

Con questa versione il problema non si presenta piu’. Nel changelog
pero’ non trovo niente di rilevante.
Mi rimane solo da fare l’upgrade della versione che ho sulla mia
macchina (MacOS X 10.4, ruby-1.8.4) per cercare
di capire se il problema e’ solo di Ruby o se c’e’ un “concorso di
colpa” di Debian.

On Jan 30, 2007, at 3:43 PM, Massimiliano M. wrote:

On 1/30/07, Stefano C. [email protected] wrote:

Ok, c’e’ qualcosa che non va.
Intanto che io mi rompo la testa per cercare il colpevole (sospetto
fortemente il compilatore gcc), qualcuno
ha una vaga idea di come CASPITA sia possibile?

Se posti un testcase lo faccio girare su sid.

Questo e’ il sorgente completo:

–begin–
#!/usr/bin/env ruby

require ‘dbi’

def test1
dbh = DBI.connect(“dbi:Mysql:host=…;database=…”, “…”, “…”)
r = dbh.execute(‘select MYFIELD from MYTABLE where MYID = 1’) #
MYFIELD e’ un tinyint
xx = r.fetch_array
puts xx[0].inspect
end

test1
–end–

In questo momento, se la variabile si chiama “xx”, l’output e’
“0” (stringa); se la variabile
si chiama “x” l’output e’ 0 (intero).
MA… se nella versione “xx” metto un require a caso in cima (p.e.
require “tempfile”), l’output
diventa quello della versione “x”. Sono piuttosto basito.
Di solito lavoro su sistemi FreeBSD (e MacOS X per lo sviluppo), e
una cosa del genere non m’e’ mai capitata.

Le versioni:
server mysql 4.0.27
client mysql 4.1 compilato a mano dai sorgenti di mysql.com
ruby 1.8.5 (2006-08-25) [i486-linux]
ruby-dbi 0.1.1
mysql-ruby 2.7.3
rubygems 0.9.0

On 1/30/07, Stefano C. [email protected] wrote:

In questo momento, se la variabile si chiama “xx”, l’output e’
“0” (stringa); se la variabile
si chiama “x” l’output e’ 0 (intero).

Confermo l’anomalia anche se invertita (0 se xx, “0” se x).

MA… se nella versione “xx” metto un require a caso in cima (p.e.
require “tempfile”), l’output
diventa quello della versione “x”.

Confermo anche questa (con require “tempfile” in testa, in entrambi i
casi ottengo “0”).

Versioni (tutto stock .deb):

[email protected]:~$ dpkg --status mysql-client-5.0 | grep Version
Version: 5.0.22-3
[email protected]:~$ dpkg --status mysql-server | grep Version
Version: 5.0.22-3
[email protected]:~$ dpkg --status ruby | grep Version
Version: 1.8.2-1
[email protected]:~$ dpkg --status libdbi-ruby | grep Version
Version: 0.1.1-4
[email protected]:~$ dpkg --status libdbd-mysql-ruby | grep Version
Version: 0.1.1-4


Massimiliano M.
code: http://dev.hyperstruct.net
blog: http://blog.hyperstruct.net

On Jan 30, 2007, at 5:44 PM, Stefano C. wrote:

Mi rimane solo da fare l’upgrade della versione che ho sulla mia
macchina (MacOS X 10.4, ruby-1.8.4) per cercare
di capire se il problema e’ solo di Ruby o se c’e’ un “concorso di
colpa” di Debian.

Contrordine! Continuando a permutare le possibilita’ alla fine
l’errore e’ tornato, e sono riuscito anche
a riprodurlo sul Mac con la 1.8.5p12. Ora dovrei installare la stable-
snapshot sul Mac e riprovare, ma a questo
punto sono abbastanza convinto che ci sia qualcosa che non va nella
1.8.5 (possibilmente quando interagisce con
DBI/Mysql).

On Jan 31, 2007, at 10:36 AM, Francesco wrote:

On Wed, 31 Jan 2007 09:27:08 +0100, Stefano C. wrote

On Jan 30, 2007, at 9:37 PM, David W. wrote:

E… usando altre lettere? Che risultati ottieni?

Non ho provato proprio TUTTO l’alfabeto, ma sono abbastanza sicuro
che non dipenda dalle lettere :slight_smile:

Ho fatto dele prove con ruby 1.8.5 e postgresql, il risultato è
sempre un Fixnum

Gia’, secondo me il problema e’ specifico di Mysql (non so se a
livello di DBD
o di driver nativo).
Gia’ in passato mi era capitato il problema dei tinyint che
diventavano stringhe,
ma almeno il comportamento era consistente e non dipendeva dai nomi
delle variabili! :slight_smile:


Stefano C.
[email protected]

On 1/30/07, Stefano C. [email protected] wrote:

Ok, c’e’ qualcosa che non va.
Intanto che io mi rompo la testa per cercare il colpevole (sospetto
fortemente il compilatore gcc), qualcuno
ha una vaga idea di come CASPITA sia possibile?

Se posti un testcase lo faccio girare su sid.


Massimiliano M.
code: http://dev.hyperstruct.net
blog: http://blog.hyperstruct.net

On Wed, 31 Jan 2007 09:27:08 +0100, Stefano C. wrote

On Jan 30, 2007, at 9:37 PM, David W. wrote:

E… usando altre lettere? Che risultati ottieni?

Non ho provato proprio TUTTO l’alfabeto, ma sono abbastanza sicuro
che non dipenda dalle lettere :slight_smile:

Ho fatto dele prove con ruby 1.8.5 e postgresql, il risultato è sempre un
Fixnum

require ‘dbi’

def test1
dbh = DBI.connect(‘dbi:PG:pippo:localhost’,‘socialman’, ‘globalman’)
r = dbh.execute(‘select num from pluto where id = 1’)
xx = r.fetch_array
puts xx[0].class

r1 = dbh.execute(‘select num from pluto where id = 1’)
x = r1.fetch_array
puts x[0].class

end
test1

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs