Problem mit Storable
hotti
- perl
naja, nicht wirklich, aber interessant:
use Storable;
store %table, 'file';
speichert mir %table in der Datei 'file', soweit ok.
Nun habe ich %table an eine eigene Klasse gebunden
tie %table, 'myClass';
kann speichern, siehe oben, aber beim
$hashref = retrieve('file');
meckert Perl, dass 'myClass' gebraucht wird. Interessanterweise funktioniert retrieve() ohne Fehlermeldung und damit auch ohne myClass, wenn ich nicht den Hash speichere, sondern das Objekt:
$obj = tied %table;
store $obj, 'file';
Beim Wiederherstellen jedoch wird mir
$hashref = retrieve('file');
als Instanz der Klasse myClass geliefert wie Data::Dump zeigt.
Isses n Bug, dass Storable die fremde Klasse mitschleppt oder hab ich was übersehen?
Hotti
aber beim
$hashref = retrieve('file');
meckert Perl, dass 'myClass' gebraucht wird.
Kann ich nicht nachvollziehen, ich erhalte keinen Fehler oder Warnung. Produzierst du mal einen lauffähigen Fall, der den normalen Ansprüchen an Fehlerberichten genügt?
hi,
Kann ich nicht nachvollziehen, ich erhalte keinen Fehler oder Warnung. Produzierst du mal einen lauffähigen Fall, der den normalen Ansprüchen an Fehlerberichten genügt?
Wie schon gesagt, es ist nicht wirklich ein Problem und auch nicht akut. Ich habe hier eine etwas ältere Perl-Version und wie ich CPAN kenne sowie anhand Deiner Worte "kann nicht nachvollziehen" denke ich, dass die Sache mit neueren Versionen schon längst aus der Welt ist.
Nichtsdestoweniger, ich habe derzeit hier:
This is perl, v5.6.1 built for MSWin32-x86-multi-thread
;# $Log: Storable.pm,v $
;# Revision 1.0.1.11 2001/07/01 11:22:14 ram
Das ist sooo hornalt, da wäre ein Bugreport schon vor dem Schreiben verjährt ;-)
Falls ich zukünftig mal in die Verlegenheit komme, das Modul produktiv einzusetzen, werde ich mir die Sache auf jeden Falle genauer anschauen.
Vielen Dank für Deine Rückmeldung,
Grüße an Alle,
Horst Klammeraffe@
Moin Moin!
This is perl, v5.6.1 built for MSWin32-x86-multi-thread
;# $Log: Storable.pm,v $
;# Revision 1.0.1.11 2001/07/01 11:22:14 ram
Mal so am Rande: Dir ist bewußt, dass sich das Dateiformat von Storable mit jeder Version von Storable bzw. Perl ändern kann und sich auch oft genug geändert hat? Noch dazu ist das Format auch noch abhängig von der Architektur des Rechners.
Kompatibilität gibt es nur ansatzweise, man kann alte Storable-Files in ein neues Storable einlesen, aber man kann mit einem neuen Storable keine Files im alten Format erzeugen. Und über Architekturgrenzen hinweg geht schon mal gar nichts.
Storable ist gut, um "mal eben" ein paar Daten aus dem Speicher zu schaffen, die man "gleich" wieder braucht. Vielleicht auch über Prozessgrenzen auf der selben Maschine hinweg. Vor allem aber schnell.
Aber als Langzeit-Speicher ist Storable völlig ungeeignet, eben wegen der o.g. Probleme. Leider steht das so klar nicht in der Doku, und leider gibt es im Core (sprich: im perl-xxx.tar.gz) kein anderes Modul, was Daten schnell, sicher und portabel[1] speichert und wieder liest. Data::Dumper kann man zwar mißbrauchen, aber es braucht ein String-Eval, das ist gruselig langsam und vor allem gruselig unsicher.
Wenn Du Daten über verschiedene Perl-Installationen hinweg austauschen willst, und / oder auf die von Storage vorgelegte Geschwindigkeitsoptimierung verzichten kannst[2], nimm etwas anderes. DBI mit DBD::SQLite wäre ein Ansatz, JSON::XS ein anderer, notfalls auch XML::LibXML oder irgendeine YAML-Library. Allen gemeinsam ist aber der Haken, dass Du die Perl-Strukturen erst einmal selbst serialisieren und deserialisieren mußt, oder Dir ein dafür geeignetes Modul suchen mußt. Und im Core sind die Libraries auch nicht.
Alexander
[1] nicht dass Storable ein portables Format hätte
[2] Ja, Du kannst. Meistens. Sehr oft bremst I/O zur Platte oder zum Netz so stark, dass selbst massive Geschwindigkeitsunterschiede beim Serialisieren / Deserialisieren nicht auffallen. Erst recht, wenn Du vergleichsweise kleine Datenmengen hin und her schiebst.