पर्ल

Question

के लिए डेटा स्ट्रक्चर के सरल, आधुनिक, मजबूत, पारदर्शी दृढ़ता, मैं पारदर्शी रूप से पर एक समाधान की तलाश कर रहा हूं, परिपत्र संदर्भों के बिना पर्ल डेटा संरचनाओं (ऑब्जेक्ट्स भी नहीं, लेकिन वस्तु समर्थन एक प्लस होगा) जारी रहेंगे। मुझे बैकएंड के बारे में बहुत कुछ परवाह नहीं है, लेकिन मैं JSON पसंद करूंगा। वस्तुओं की संख्या अपेक्षाकृत कम होगी (कुछ हज़ारों हैशफ प्रत्येक के साथ लगभग 5 कुंजी)। "पारदर्शी" दृढ़ता से मेरा मतलब है कि जब भी मैं इन-मेमोरी डेटा संरचना अद्यतन करता हूं, तो मैं भंडारण बैकएंड में परिवर्तन नहीं करना चाहता हूं। कोई अद्यतन 2003

ब्रायन डी के बाद से -

• डेव Rolsky के मॉड्यूल के Perl Object-Oriented Persistence संकलन:

  my $ds; 
  
  ... 
  # load the $ds data structure from 'myfile' 
  
  print $ds->{foo}->{bar}; # baz 
  $ds->{foo}->{bar} = 'quux'; 
  
  ... program dies, but the updated %hash has been persisted automatically in 'myfile' 
  
  # in another invocation 
  print $ds->{foo}->{bar}; # quux 
  

  अब तक मैं देखा है:

  यहाँ कोड आदर्श की तरह यह कैसी दिखाई देगी फोय का MasteringPerl - Chapter 14. Data Serialization - डीबीएम :: दीप, एक अच्छा उम्मीदवार के बारे में बात करता है। मेरी इच्छा है कि धारावाहिक और पारदर्शी दृढ़ता के बीच एक स्पष्ट अंतर था।

• Persistent - कोई अद्यतन 2000
• SPOPS के बाद से - 2004
• SLOOPS केवल CPAN पर एक संस्करण है के बाद से परित्यक्त 2005
• Tangram से - बहुत छोड़ दिया लग
• Tie::File::AsHash पारदर्शी हठ, लेकिन केवल single-level hashes का समर्थन करता है है
• MooseX::Storage, Storable और JSON अच्छा लग रहा है, लेकिन वे केवल क्रमबद्ध हैं, जारी नहीं रहते खिलाडि़यों चौखटे
• DBIx::Class, Class::DBI, Fey::ORM, ORM, Rose::DB OO-RDBM मानचित्रकारों हैं, और I'd rather not use a database backend
• DB_File BerkeleyDB की आवश्यकता है
• KiokuDB कार्य

मैं केवल एक मिल गया है के लिए बहुत जटिल लगता है वादा मॉड्यूल, DBM::Deep। कोड उदाहरण के समान है, और आप डेटा संरचना को

my $ds = DBM::Deep->new("myfile.db"); 

प्रारूप बाइनरी के साथ लोड कर सकते हैं। कोई बड़ी समस्या नहीं है, क्योंकि मैं इसे मानव-पठनीय प्रारूप में निर्यात करने के लिए JSON का उपयोग कर सकता हूं।

तो, क्या मैं एक मॉड्यूल खो रहा हूं, और क्या मैं समस्या को सही तरीके से देख रहा हूं?

Answer 1

अपने "पारदर्शिता" लक्ष्य को प्राप्त करने के लिए, आप इसे एक ढांचे में या तो सार करने के लिए है (जैसा कि chambwez सुझाव) याउपयोग करने के लिए जा रहे हैंडी चर जो स्वचालित रूप से डिस्क पर सहेज लेते हैं जब भी वे अपडेट होते हैं। इस तरह से डीबीएम हैश tie का उपयोग करते हैं, इसलिए DBM::Deep शायद आपकी सबसे अच्छी शर्त है; अन्य सभी चीज़ों के बारे में मुझे पता है कि प्रदर्शन के नाम पर डेटा आउट और/या कैश लिखने के लिए आपको स्पष्ट रूप से यह बताना होगा।

Answer 2

JSON का उपयोग क्यों नहीं करें? यह बल्कि आसान है (जब तक मैं आपके सवाल का गलत समझा), तुम सब होता यह है:

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; 

एक और आसान बात आप कर सकते हैं Data::Dumper का उपयोग करें।

Answer 3

मुझे नहीं लगता कि पारदर्शी दृढ़ता बहुत अच्छा विचार है। मान लें कि आपके पास काल्पनिक कार्यान्वयन है जो बाहरी दुनिया में perl डेटा संरचना से संबंध रखता है। पारदर्शी होने के लिए, संरचना में प्रत्येक लेखन का पता लगाया जाना चाहिए और अद्यतन के बाहर डेटा होना चाहिए।यह शायद बहुत महंगा हो जाएगा और बहुत सारी डिस्क गतिविधि के साथ समाप्त हो जाएगा जब तक कि आपके पास तेजी से यादृच्छिक पहुंच के साथ परिष्कृत बैकएंड न हो। मैं कल्पना नहीं कर सकता कि JSON फ़ाइल के अपडेट कुशल हो।

कुछ विकल्प:

• उपयोग डेटाबेस बैकएंड (डी बी एम :: दीप, DB_File या KiokuDB)
बैकएंड के रूप में
• उपयोग कुंजी-मान की दुकान (Memcached, Redis)
• डेटा पर संगत कार्यप्रवाह को परिभाषित करने और क्रमानुसार/अच्छा पल में deserialize