User since
2003-08-04
7321
Artikel
ModeratorIn
Was sind eure Erfahrungen?
Was würde ihr warum vorziehen?
Ein Nachteil von Storeable z.B. ist, dass es versionsabhängig ist.
Gibt es alternativen?
User since
2003-08-04
7321
Artikel
ModeratorIn
Hab grad Data::Serializer entdeckt.
Das ist ja toll; dass wollte ich gerad schon nachschreiben! :)
User since
2003-11-28
3645
Artikel
ModeratorIn
Ich habe mal ein Dokument angefangen, in dem CPAN-Module miteinander verglichen werden. Zu Serialisierungs-Modulen steht da:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
=head1 Serialization
L<YAML> is neat: it's human readable, portable across languages, but
unfortunately the Perl implementation is buggy so that's unusable
(other than for configuration files).
L<Storable> is in the core since 5.7.3. It's fast (because implemented
in XS and using a binary format), but it's not human readable. The
file format is forward compatible and the module versions are backward
compatible, which means you can read all Storable-generated files with
a recent Storable version, but only a Storable file generated by an
old version can be read by all Storable versions. Storable has neat
features like customizable per-class hooks and the ability to
(de)serialize code references.
L<Data::Dumper> is in the core since 5.005. The output is
human-readable as it's perl code. Data::Dumper comes with an optional
XS part, but has also a pure-perl part. Deserializing is done through
eval() which is probably dangerous, Safe::reval should be preferred.
Deserializing is a little bit unhandy. Data::Dumper is also able to
serialize code references.
L<Data::Dump::Streamer> is maybe worthwhile to take a look on XXX.
L<Data::Denter> is a predecessor of YAML.
L<Data::Serializer> is a meta class for handling a couple of
serialization methods together with encryption, compression and
checksumming.
User since
2003-08-04
7321
Artikel
ModeratorIn
es gibt wohl auch XML::Dumper!
User since
2003-11-28
3645
Artikel
ModeratorIn
[quote=esskar,17.02.2005, 13:16]es gibt wohl auch XML::Dumper![/quote]
Danke, habe jetzt folgendes ergaenzt:
L<XML::Dumper> is a serialisation module for dumping Perl objects
from/to XML. As usually with XML, the output is very verbose and
probably slower than other modules. It's possible to include a DTD in
the generated XML document. There's no support for code references.
L<FreezeThaw> is ancient, pure-perl, and much slower than other
modules.
User since
2003-08-07
2921
Artikel
BenutzerIn
XML::Dumper finde ich aber nicht so toll, ist mir zu kompliziert und die Datenstrukturen müssen ein bestimmtes Foirmat haben (Arrayreferenzen) bzw. werden in dieses umgewandelt. Data::Serializer ist da schon besser, es übernimmt genau die Datenstruktur die man reingibt.
Ich benutze das gerne, es scheint mir auch von der Benutzung recht komfortabel.
mfg pktm
User since
2003-08-04
7321
Artikel
ModeratorIn
[quote=pktm,17.02.2005, 16:53]Data::Serializer ist da schon besser, es übernimmt genau die Datenstruktur die man reingibt.
Ich benutze das gerne[/quote]
du kannst Data::Serializer auch sagen, dass es XML::Dumper benutzen soll!
User since
2003-11-28
3645
Artikel
ModeratorIn
[quote=pktm,17.02.2005, 16:53]XML::Dumper finde ich aber nicht so toll, ist mir zu kompliziert und die Datenstrukturen müssen ein bestimmtes Foirmat haben (Arrayreferenzen) bzw. werden in dieses umgewandelt.[/quote]
Das stimm ja nicht, es gibt durchaus auch hashref und scalarref bei XML::Dumper. Wie die serialisierte Struktur aussieht, ist eigentlich auch uninteressant, es sei denn, man will die Ausgabe als Mensch lesen koennen (zum Debuggen z.B.), dann nimmt man Data::Dumper oder man will sie auch editieren, dann nimmt man YAML. Wichtiger waere fuer mich die Geschwindigkeit, die Verfuegbarkeit (Standardmodul?) und wie komplett es ist.
User since
2003-08-04
7321
Artikel
ModeratorIn
dann mal noch so ne frage zum thema: ist es gang und gäbe solche serializer zu nutzen? also ich meine in applikationen. Hab mir z.B. einen ObjectLoader geschrieben, der mit hilfe von Data::Serializer ein Object auf die Platte jagt oder von dort liesst. Find sowas aber teilweise kritisch, da man dieses file austauschen und kritische daten ins programm schmuggeln könnte; klar, dies kann auch passieren, wenn für das Object z.b. eine Ini-Datei geladen und gespeichert würde. dann müsste ich zwar immer noch die einträge testen, dann kann ich aber selbst entscheiden ob ich mir mit den daten ein object zusammen baue mit dem ich arbeite. also wie gefährlich und alltagstauglich ist das ganze?\n\n
<!--EDIT|esskar|1108836884-->
User since
2003-08-04
7321
Artikel
ModeratorIn
dann mal anders gefragt: wie speichert ihr die daten, wenn gerade keine Datenbank zur Hand steht? Und geht ihr davon aus, dass alles was dort in der Datei steht mit rechten Dingen zu geht?