2012-03-06 13 views
5

Ho un oggetto perl (riferimento ad array di riferimenti) come di seguito:Memorizzazione oggetto sul DB e recuperarlo

my $a = [ [$a, $ab, $c ], [$a, $b, $c] ] ; 

e la necessità di memorizzare sul DB poi recuperarlo.

Qualcuno potrebbe suggerire un buon meccanismo per serializzare anche per comprimerlo e quindi memorizzarlo sul DB? Quindi deserializzare e usarlo nel codice?

risposta

7

È possibile utilizzare uno qualsiasi dei serializzatori noti, ad es. JSON::XS o Storable. Storable è meglio se si desidera recuperare i riferimenti come riferimenti, non come copie di valori. Quindi salva un oggetto serializzato nel campo di qualsiasi tipo (VARCHAR, BLOB, ...) che soddisfi i requisiti di archiviazione.

use Storable qw(nfreeze thaw); 
use DBI; 

# ... connect to database 
# Store 
my $data = [ [$a, $b, $c ], [ $a, $b, $c ] ]; 
my $bytestream = nfreeze $data; 
$dbh->do('insert into table (field) values(?)', undef, $bytestream); 

# Retrieve 
$bytestream = $dbh->selectrow_array('select field from table where ...'); 
$data = thaw $bytestream; 

Inoltre, è possibile comprimere $bytestream, per esempio, tramite IO::Compress::Gzip

my $bytestream = gzip nfreeze $data; 
+0

L'ho provato ma ottengo il seguente errore: Impossibile chiamare il metodo "nfreeze" sul riferimento non trattato – smith

+0

Il metodo di importazione è 'nfreeze'? Usa 'qw (nfreeze) memorizzabile 'o scrivi un nome completo del metodo:' Storable :: nfreeze ($ data) '. – Ali

+0

hai ragione grazie, anche qual è il modulo che decomprime gzip? – smith

-1

Non l'ho mai provato, ma perldoc dice che il valore di ritorno di Data :: Dumper può essere "valutato per ottenere una copia identica della struttura di riferimento originale". È quindi possibile inserire l'output del Dumper in un campo di testo abbastanza grande nel database.

+1

-1, questo permetterebbe un attacco di iniezione SQL per degenerare ad un attacco di esecuzione di codice remoto. 'eval STRING' dovrebbe essere usato con molta cautela con qualsiasi dato che non sia generato nel suo insieme dal programma che chiama' eval STRING'. –

-1

Che dire di Data :: Dumper? È possibile eseguire il dump degli oggetti in un campo TEXT del DB e quindi valutare il contenuto per recuperarlo.

+0

-1, ciò consentirebbe a un attacco di iniezione SQL di passare a un attacco di esecuzione di codice in modalità remota. 'eval STRING' dovrebbe essere usato con molta cautela con qualsiasi dato che non sia generato nel suo insieme dal programma che chiama' eval STRING'. –

+0

Anche se sono d'accordo sul fatto che dovresti tenerlo a mente, l'OP non ha detto nulla su dove sono stati generati i suoi dati. Quindi non vedo alcun motivo per non prendere in considerazione Data :: Dumper. – fenton

+0

Il mio commento non è da dove i dati sono * destinati * a venire, ma da dove * potrebbe * venire. L'idea di [Defense in Depth] (http://en.wikipedia.org/wiki/Defense_in_depth_%28computing%29) deve essere proattiva sulla sicurezza a ogni livello di un'applicazione per evitare che un buco in un livello comprometta il prossimo strato. Se chiamate mai "eval STRING" su qualsiasi dato che è ritornato dal vostro database, avete dato al vostro database pieno accesso al codice di esecuzione nella vostra applicazione. Qualsiasi violazione del tuo database ora ha il pieno controllo dell'intera applicazione. ** Non eseguire i dati! ** –

Problemi correlati