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?
Non ho provato proprio TUTTO l’alfabeto, ma sono abbastanza sicuro
che non dipenda dalle lettere
Ma sono riuscito anche a produrre risultati piu’ inquietanti… per
esempio:
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).
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…
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.
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
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 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
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!
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?
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
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.
