Je cherche une solution pour de transparence em> Persist Perl Structures de données (pas même des objets, mais la prise en charge des objets serait un plus) sans références circulaires. Je m'en fiche beaucoup sur le backend, mais je préférerais Json. Le nombre d'objets serait relativement faible (quelques milliers de hashrefs avec environ 5 clés). Par la persistance "transparente", je veux dire que je ne veux pas avoir à commettre des modifications au backend de stockage à chaque fois que je mettez à jour la structure de données en mémoire. Voici comment le code serait parfaitement: P> < Pré> xxx pré> jusqu'à présent, j'ai regardé: p> Je n'ai trouvé qu'un module prometteur, DBM :: profond < / a>. Le code est comme dans l'exemple et vous pouvez charger la structure de données avec P> le format est binaire, cependant. Pas un gros problème, car je peux utiliser Json pour l'exporter dans un format lisible par l'homme. P> Donc, je manque un module et je suis à l'abri correctement du problème? P> < / p>
3 Réponses :
Pourquoi ne pas utiliser JSON ? C'est plutôt facile (sauf si j'ai mal compris votre question), tout ce que vous feriez, c'est que:
use JSON; # serialize to file open(my $fh, ">myfile"); print $fh encode_json($ds); close $fh; # deserialize from file open(my $fh, "<myfile"); local $/ = undef; my $content = <$fh>; $ds = decode_json($content); close $fh;
Je cherche une persistance transparente (j'espère que c'est le terme correct?) Par la persistance "transparente", je veux dire que je ne veux pas avoir à commettre des modifications au backend de stockage à chaque fois que je mettez à jour la structure de données en mémoire. J'ai édité la question; Merci d'avoir souligné cela.
Je ne pense pas que la persistance transparente est une très bonne idée. Supposons que vous ayez une implémentation hypothétique qui lie la structure de données PERL au monde extérieur. Pour être transparent, chaque écriture dans la structure doit être détectée et les données extérieures à jour. Cela va probablement être assez coûteux et se terminer par beaucoup d'activité de disque à moins que vous n'ayez de backend sophistiqué avec un accès aléatoire rapide. Je ne peux pas imaginer que les mises à jour du fichier JSON soient efficaces. P>
Certaines options: p>
Pour atteindre votre objectif de "transparence", vous devez être abstrait dans un cadre (comme la Chambwez suggéré) ou utilisez des variables code> D qui se sauveront sur un disque chaque fois qu'ils " re mis à jour. DBM HASHES Utilisez Cravate Code> de cette manière, donc
dbm :: profond code> est probablement votre meilleur choix; Tout ce que je suis au courant de vous demander de lui dire explicitement lorsque vous écrivez des données et / ou des caches écrit au nom de la performance. P>