OOPS - Object Oriented Persistent Store
use OOPS; transaction(sub { $oops = new OOPS dbi_dsn => $DBI_DSN, username => $username, password => $password, table_prefix => "MY"; $oops->commit; $oops->{my_1st_bit_of_data} = 'a scalar'; $oops->{my_2nd_bit_of_data} = { A => 'hash' }; $oops->{my_3rd_bit_of_data} = [ qw(An Array) ]; $oops->{my_4rd_bit_of_data} = \'a reference to a scalar, ref, hash, or array' ]; my $old_value = $oops->{multiple}{level}{dereference}; my $object = $oops->load_object($integer_object_id); my $dbh = $oops->dbh(); $oops->workaround27555($reference); my $was_virtual = $oops->virtual_object(\%{$oops->{some}{hash}, [ $new_value ]); }); my $ref = getref(%hash, 'key')
The goal of OOPS is to make perl objects transparently persistent. OOPS handles deeply nested and cross-linked objects -- even object hierarchies that are too large to fit in memory and (with a hint) individual hash tables that are too large for memory. Objects will be demand-loaded into memory as they are accessed. All changes to your object hierarchy will be saved with a single commit().
Full transactional consistency is the only operational mode. Either all of your changes are saved or none of them are. While your program runs, you will see a consistent view of the data: no other running transactions will change the data you see. If another transaction changes data that you are using then at least one of the transactions must abort. OOPS will die() to abort the transaction.
OOPS maps all perl objects to the same RDBMS schema. No advance schema definition is required on the part of the user of OOPS. The name of the package (OOPS) comes from the realization that perl's data model is much more complicated than I initially understood. Internally, the RDBMS schema uses four tables: a table of objects, a table of attributes (keys and values), a table of large attributes that big the normal column widths, and a table of counters.
At this time, OOPS is expecting a web-like work flow:
create OOPS instance access some objects modify some objects commit exit
If you need more than one transaction in a program, create more than one OOPS instance.
To make your data persistent, make a reference to your data from the OOPS object. To later retrieve your data, simply access it through the OOPS object.
use OOPS; transaction(sub { my $oops = new OOPS dbi_dsn => 'DBI:mysql:database=MY-DATABASE-NAME;host=localhost', username => 'MY-USERNAME', password => 'MY-PASSWORD', table_prefix => "MY-TABLE-PREFIX"; my $p = $oops->{pages}{"/some/path"}; $p->{next} = $oops->{pages}{"/some/other/path"}; $p->{jpgs} = [ read_file("x.jpg"), read_file("y.jpg") ]; $oops->commit; }); exit;
Perl HASHes, REFs, SCALARs, and ARRAYs are supported. Currently, HASH keys may not be longer than 255 characters. Class names may not be more than 128 characters long. References to hash keys and array elements are supported.
At the current time, large ARRAYs are not efficient. Use HASHes instead if this matters to you. References to array elements and hash values are not efficient.
Large HASHes are supported by only loading keys that are accessed.
HASHes, array elements, and REFs are implemented with tie(). ARRAYs are not currently tie()d because of bugs in perl. Multiple references to the same scalar are supported. References to array elements and hash values are supported. Persistent data is reference counted and cycles must be manually broken to assure de-allocation.
The following RDBMSs are supported in the code:
OOPS 1.004 has been tested with PostgreSQL version 8.1.4 on Linux. OOPS 1.003 was tested with 7.4.2 and 7.3.5 on Linux and 7.3.5 on pre-release DragonflyBSD. Somewhere between 7.4.2 and 8.1.4 PostgreSQL got more strict about TEXT versus BYTEA types. OOPS 1.003 was using TEXT where it should have been using BYTEA. Be sure to upgrade OOPS to 1.004 *before* upgrading PostgreSQL to 8.x.
Biggest issue: PostgreSQL runs the test suite slowly.
OOPS 1.004 has been tested with mysql 4.1.15 on Linux. OOPS 1.003 was tested with mysql 4.0.16 and 4.0.18 using InnoDB tables.
The OOPS schema for mysql does not support large (>256 byte) hash keys.
Biggest issue: Mysql 4.1.15 (at least) detects some deadlocks very slowly. http://bugs.mysql.com/bug.php?id=20857.
DBD::SQLite versions 0.x use SQLite 2.x. DBD::SQLite versions 1.x use SQLite 3.x. Unfortunately, the 1.x versions of DBD::SQLite that have been tested with OOPS have failed to pass. They die consistently a few thousand transactions in on certain tests. Use DBD::SQLite2 instead.
If you're using OOPS 1.003 and DBD::SQLite 0.x then upgrade OOPS to 1.004 and switch to DBD::SQLite2. Make both changes at the same time.
OOPS 1.004 has been tested with DBD::SQLite2 0.33. OOPS 1.003 was tested with DBD::SQLite 0.31. Use DBD::SQLite 1.x at your own risk -- versions 1.11 and 1.12 cannot pass the OOPS regression tests.
DBD::SQLite2 is not 8-bit clean with respect to \0. OOPS uses a DBD::SQLite2 feature to translate binary nulls. A side-effect is that backslash will be doubled \ -> \\ in DBD::SQLite2 (the extras will be removed transparently by DBD::SQLite2. OOPS does not use the counters table with DBD::SQLite2 (or DBD::SQLite). As of 1.004, OOPS doesn't make use of the newer (version 1.x) DBD::SQLite features for handling nulls.
\0
\
\\
counters
http://www.hwaci.com/sw/sqlite/
Biggest issues: SQLite3 fails (http://rt.cpan.org/Ticket/Display.html?id=20286); SQLite3 leaks memory (http://rt.cpan.org/Ticket/Display.html?id=20288); SQLite2 and SQLite3 both do database-level locking only.
Perl versions 5.8.2 through 5.8.7 are supported. Prior to 5.8.2, it wasn't possible to untie scalars from within the a tied scalar access method. An ugly workaround is possible if there is enough interest.
OOPS 1.004 has been tested on Linux 2.6.15 (Ubuntu 6.06LTS - Dapper Drake). OOPS 1.003 was tested on Linux 2.4.23 (Debian unstable as of April '04); on FreeBSD 4.9; and on DragonflyBSD prerelease.
As far as performance goes, mysql and SQLite are both about twice as fast as PostgreSQL for applications that only have one transaction at at time. SQLite is particularly slow when there are multiple transactions as its lock granularity is the entire database. Mysql also slows down when there are multiple simultaneous transactions. I don't know yet which back-end is fastest for applications with many simultaneous transactions.
The RDBMS schema for SQLite is different than for mysql or PostgreSQL (which are nearly the same as each other).
transaction($funcref, @args)
transaction() is a wrapper for a complete transaction. Transactions that fail due to deadlock with other processes will be re-run automatically.
transaction()
The first parameter is a reference to a function. Any additional parameters will be passed as parameters to that function. The return value of transaction() is the return value of &$funcref().
&$funcref()
It is not necessary to use the transaction() method. Beware that nearly any operation on persistent date (even read operations) can cause deadlock.
Any use of persistent data can trigger a deadlock. The transaction() function catches this and retries automatically up to $OOPS::transaction_maxtries times (15 times unless you change it). If you don't use transaction() you might want to catch the exceptions that transaction() catches. To do this, you can regex match $@ against $OOPS::transfailrx.
$OOPS::transaction_maxtries
$@
$OOPS::transfailrx
Basically, transaction is a slightly fancier version of the following:
sub transaction { my ($sub, @args) = @_; for (0..15) { eval { &$sub(@args); } last unless $@; next if $@ =~ /$OOPS::transfailrx/; die $@; } }
The important thing to notice is that your code will be called over and over until the transaction succeeds. This means you should write your code so that it doesn't have any external side effects until after it calls commit().
getref(%hash, $key)
References to tied hash keys are buggy in all perls through 5.8.7 (and beyond?). Use getref(%hash, $key) to create your reference to a tied hash key. See: http://rt.perl.org/rt3/Ticket/Display.html?id=27555 and http://rt.perl.org/rt3/Ticket/Display.html?id=29224.
$ref = getref(%hash, $key);
Alternatively, use $oops->workaround27555($ref).
$oops->workaround27555($ref)
Getref() and workaround27555() work around all the perl bugs with tied hash key references. Failure to use them may result in unexpected and inconsistent results.
OOPS->new(%parameters)
Creates a OOPS object instance. More than one object instance is allowed at the same time. Instances are unaware of each other. Making a reference from a persistent object in one instance to a persistent object in another instance will cause recursive copying from one instance to the other. (Untested).
The %parameters are documented in the next section.
%parameters
OOPS->initial_setup(%parameters)
Drops and recreates the database tables. Don't use it too often :-) The regression suite drops and re-creates the tables many times.
The new() and initial_setup() methods take a hash specification for their behavior. Here are the parameters allowed:
new()
initial_setup()
dbi_dsn
$ENV{OOPS_DSN}
$ENV{OOPS_DRIVER}
$ENV{DBI_DSN}
$ENV{DBI_DRIVER
Many ways to specify the DSN for DBI: as an argument; as an OOPS environment variable; as a DBI environment variable. Use at least one :-) See the DBI documentation for more details.
user
$ENV{OOPS_USER}
$ENV{DBI_USER}
Three ways to specify the user for DBI: as an argument; as an OOPS environment variable; as a DBI environment variable. Not required for all databases.
password
$ENV{OOPS_PASS}
$ENV{DBI_PASS}
Three ways to specify the password for DBI: as an argument; as an OOPS environment variable; as a DBI environment variable. Not required for all databases.
table_prefix
$ENV{OOPS_PREFIX}
OOPS allows a prefix to be supplied for it's internal table names. If you set a prefix of FOO_ then it will use a FOO_object table instead of an object table. This can be set as an argument to new() or it can be set with the environment variable $OOPS_PREFIX. This allows multiple separate object spaces to exist within the same backend SQL database. It's intended use is to support testing vs. production environments but it could also be used to segregate object spaces that don't link to each other.
FOO_
FOO_object
object
$OOPS_PREFIX
The current tables and indexes are:
Each row is an object.
Each row is an attribute value in an object.
Each row is a large attribute value.
Counters for things like object ids.
A temporary table.
Object grouping index.
Lookup by attribute value.
auto_upgrade
$ENV{OOPS_UPGRADE}
The relational schema for OOPS is not same for all versions of OOPS. If this is set, then an older schema will be upgraded to the current schema. If this is not set, then OOPS will use the older schema unchanged. In most cases, this means that OOPS will use a historical version of itself rather than the current version. See the SCHEMA VERSIONS section of this document.
auto_initialize
$ENV{OOPS_INIT}
The DBMS must be initialized before it can be used: tables created, a few rows inserted, etc. This can be handled by calling initial_setup() or it can be handled automatically by new() if auto_initialize or $OOPS_AUTO_INIT is set.
$OOPS_AUTO_INIT
default_synchronous
$ENV{OOPS_SYNC}
With SQLite, an additional parameter to OOPS->new() is recognized: default_synchronous. Possible values are:
OOPS->new()
Sync() all transactions to disk before returning.
The default: sync() at critical moments only - protects against program failure, but not all power or OS failures.
Don't sync() at all and go really fast.
->commit()
Writes any changed objects back to the database and commits the transaction. Currently only one commit() call is allowed. Do not access your persistent data after commit() -- it may work but this is not covered well in the regression suite.
->virtual_object(\%hash [,$new_value])
Queries [and sets] the load-virtual flag on a persistent hash. Hashes that load virtual will do separate queries for each key rather than load the entire hash. This is a good thing if your has has lots of keys. This flag takes effect the next time the hash is loaded. The value is a perl boolean.
This may be handled automatically in the future.
->workaround27555($reference)
References to tied hash keys are buggy in all perls through 5.8.7 (and beyond?). Use workaround27555($reference) to register your new tied hash key references so that they can be transformed into references that actually work correctly.
$ref = \%hash{$key}; $oops->workaround27555($ref);
workaround27555() is harmless if called on other sorts of references so it is safe to use indiscriminately. See http://rt.perl.org/rt3/Ticket/Display.html?id=27555.
workaround27555()
Alternatively, use getref(%hash, $key).
->dbh()
This returns the main DBI database handle used by OOPS. This function is provided for those who want to hand-write queries. Please note: no changes are written to the DBMS until commit().
->load_object($id)
This will load a persistent object by number. It returns the object or undef if the object doesn't exists. This function is provided for those who want to hand-write queries.
OOPS has been thoroughly tested. The regression suite is very well developed: there is twice as much code in the test suite as there is in the module itself. The suite does over 1.5million tests. On my fastest computer it takes over six hours to run. I have so much confidence in my test suite, I'm offering a bounty on bugs!
I'll pay (via paypal) US$5.00 to anyone who submits a new bug (with regression test) that is caused by a problem in my OOPS module. To qualify, bugs must be serious: they must cause data corruption, false results, or program failure. Bugs must not be listed here or be *caused* by using a versions of perl, modules, or RDBMSs that are not explicitly supported.
I'll report the number of bounties paid in the CHANGELOG.
There is a mailing list for OOPS. Send a message to oops-subscribe@idiom.com to subscribe.
OOPS currently has memory leaks. This may or may not matter to your application. The rate of leakage varies depending on which RDBMS is used. SQLite seems to have the most significant problems. Most of the leaks are not in OOPS itself but in the modules it uses and thus are not easily fixed by the OOPS developers.
Additional references to the in-memory copies of persistent data are kept by OOPS. These extra references will prevent DESTROY methods from being called as soon as they otherwise would be. They'll usually be delayed until the OOPS object is itself DESTROYed.
Other perl magic attributes are not currently stored persistently. Many probably could be supported, but many could not. For example, taint does not work on tied hashes: http://rt.perl.org/rt3/Ticket/Display.html?id=6758.
When you bless a reference to a scalar value, the blessing is stored with the scalar, not the reference. The blessing remains even if there is no reference to the scalar. The following code prints true.
true
my $x = 'foobar'; my $y = \$x; bless $y, 'baz'; $y = 7; $y = \$x; my $z = ref($y); print "true\n" if $z eq 'baz';
At the current time, OOPS does not store such blessings. OOPS does remember blessings when there isn't a reference.
If you re-bless the OOPS object, your data is likely to become inaccessible. I list this here so nobody claims a bounty for breaking OOPS in this way.
DBD::Pg does not easily support ASCII NULL. OOPS has only partial support for ASCII NULL with PostgreSQL: don't have ASCII NULL in your class names.
OOPS mostly allows you to make circular self-references:
my $x; $x = \$x;
In some (rare) cases circular self-references sometimes break. Since I can't think on any good reason to make a circular self-reference, I've left this hanging.
The database schema for OOPS does not support huge hash keys in RDBMS backends.
Persistent hashes are implemented with tie. There are bugs with perl's implementation of references to tied hash keys. These bugs will be triggered in several situations: creating a reference to tied hash key that doesn't exist yet; deleting a key that has a reference tied to it; assigning through a reference to a key that has multiple references.
All of the above can either be avoided or you can workaround them by either calling workaround27555($YOUR_REFERENCE) whenever you create a tied hash key reference or by using getref(%hash, $key) to create your reference.
workaround27555
The perl bugs are documented in: http://rt.perl.org/rt3/Ticket/Display.html?id=27555 and http://rt.perl.org/rt3/Ticket/Display.html?id=29224.
local
local(%some_tied_hash) doesn't work right. Thus local(%some_persistent_hash) won't work right either: http://rt.perl.org/rt3/Ticket/Display.html?id=6017.
local(%some_tied_hash)
local(%some_persistent_hash)
scalar(%hash)
Tied scalar(%hash) support was added in perl 5.8.3 and does not exist in 5.8.2.
There are a couple of bugs with tied arrays that prevent OOPS from using them: http://rt.perl.org/rt3/Ticket/Display.html?id=22570 and http://rt.perl.org/rt3/Ticket/Display.html?id=22571. OOPS fully loads arrays into memory to work-around this problem. This isn't a big deal unless you've got big arrays.
If SQLite is used with a perl that has been compiled to use perl's malloc(), it will report LOTS of Bad free() ignored (PERL_CORE) errors. It is not currently known if these errors are harmful beyond generating lots of output to STDERR. The default perl configuration on FreeBSD uses perl's malloc().
malloc()
Bad free() ignored (PERL_CORE)
As OOPS is developed, the schema that OOPS uses changes. At the current time, all versions of OOPS use forward and backwards compatible (though not identical) schemas.
OOPS notices if the version of the schema in the DBMS is different than the version the code currently supports. When this happens there are two possibilities: either OOPS will upgrade the schema to the current version or it will use an older version of OOPS to access the data. See the auto_upgrade notes in the PARAMETERS FOR NEW section.
This behavior allows the OOPS module to be upgraded without disrupting installed applications.
OOPS isn't done. There are a bunch of things that I am considering adding to it. If any of these things is important to you, speak up so that I know there is interest...
There are bugs listed in the DEVELOPMENT STATUS section that could be fixed. First up is fixing the memory leaks that are in OOPS itself.
The initial releases of OOPS concentrated on correct behavior and other aspects of the module were somewhat ignored. The code could be cleaned up a bunch.
With the transaction model of SERIALIZABLE on mysql, there are serious performance issues surrounding access to the main hash. Change to a different transaction model or DBMS.
SELECT Employee WHERE $Employee->{salary} > 5000
It's possible to translate perl-syntax queries into real SQL that can be used to query the object store.
Objects are loaded in groups rather than individually. There is much room for improvement in choosing how groups are formed. This is largely undeveloped as yet.
Many possibilities. A cache-invalidation daemon to note when objects have changed. Re-verification of touched data from the database. Ability to call commit() more than once.
Support for persistent weak references is possible.
Currently objects are reference counted internally. You must have a reference to something from an already existing object for it to continue to exist.
OOPS has to do a lot of scanning of objects to see if they've changed. Explicit notification of changes would improve performance.
OOPS could call functions before saving and after loading to transform objects for a better or cleaner on-disk representation.
This isn't something that I care about but maybe someone else does?
Allow explicit schemas to be defined. Do not save objects that don't conform. Eg: Hash::Util::lock_keys().
Map existing RDBMS schemas into objects.
Viewing large datasets of deep and cross-linked data is difficult. Perhaps a CGI-based or Tk-based data navigator would help.
It is possible to support storing tied data. The tied object is what would need to be persistent. This would only work on some kinds of ties.
Like perl, OOPS uses reference counting to know when to delete an object. Unlike a normal program, restarting your program does not clear out the circular references.
Right now, just HASH, SCALAR, REF, and ARRAY are supported. Regular expressions, file handles, I don't know it's possible to support code references.
By doing double updates, OOPS could support live migration from one DBMS to another.
If you want to query your data, then until a translator is written, your only choice for making queries is to write them by hand. Using your data does not require a query: anything you've got a reference to will be loaded as you access it. Queries are for performing searches that don't have a perl-object index.
Each perl HASH, REF/SCALAR, or ARRAY has a row in the object table and multiple rows in the attribute and big tables.
attribute
big
Here are the columns you'll care about:
There is one row per perl object.
The object id.
The blessed class name (limited to 255 characters).
The type of object:
A HASH.
An ARRAY.
A SCALAR or REF.
This is a table of key/value pairs. The keys correspond to perl hash keys and perl array indexes. The values correspond to perl hash values and array element values.
The hash key or array index.
he hash value or array value. Limited to 255 characters.
Flags the type of the value. Possible values are:
A normal value. Numeric or string.
An big value. pval will be a copy of the start of the value for the first N characters. The end of pval will be a MD5 checksum of the full big value.
pval
A reference to another object.
This is a table of values that were too large for the normal columns. Even with databases that support wide columns, a separate big table is used so that you don't load large scalars unless you actually need the value.
The hash value or array value. Limited to whatever the underlying database will support as it's largest blob.
Blob fragment number. This column only exists with SQLite. SQLite has a smallish maximum row size and so big values must be split into multiple rows.
REFs are are special. There are several types of REFs: references to scalar values; references to objects; secondary references to scalar values; references to scalar values that are part of another object (references to hash keys and references to array elements).
The representation of references is designed so that you don't need to care what sort of REF it is when you're doing a query.
The basic REF is a ref to a value inside another object. An example:
OBJECT TABLE id class otype 1 OOPS::NamedObj H 383 SCALAR R 384 SCALAR R 385 SCALAR R 386 REF R 400 HASH H 500 ARRAY A ATTRIBUTE TABLE id pkey pval ptype 1 A500 500 R 1 H400 400 R 1 R383 383 R 1 R384 384 R 1 R385 385 R 1 R386 386 R 383 400 'a-key' 0 384 384 'nopkey' 0 384 'nopkey' 'a-value' 0 385 384 'nopkey' 0 386 386 'nopkey' 0 386 'nopkey' 500 R 400 'a-key' 'a-value 0 400 'another-key' 'another-value' 0 400 'A500' 500 R 500 0 'a-value' 0 500 1 'another-value' 0
HASH 1 is %$oops.
%$oops
REF 383 is a reference to the key 'a-key' in object #400 (a HASH).
REF 384 is a ref to scalar. It uses two rows to make writing queries easier.
REF 385 is a duplicate reference to a scalar value. It duplicates REF 384. In behavior, these two REFs should be identical even though they are represented differently in the database.
REF 386 is a ref to an object: #500 (an ARRAY).
HASH 400 is a normal hash.
ARRAY 500 is a normal hash.
This example data is what you would end up with after running code like:
my $oops = new OOPS dbi_dsn => 'DBI:mysql:database=MY-DATABASE-NAME;host=localhost', username => 'MY-USERNAME', password => 'MY-PASSWORD'; $oops->{A500} = [ 'a-value', 'another-value' ]; $oops->{H400} = { 'a-key' => 'a-value', 'another-key' => 'another-value', 'A500' => $oops->{A500}, }; $oops->{R383} = \$oops->{H400}{'a-key'}; $oops->workaround27555($oops->{R383}); $oops->{R384} = \'a-value'; $oops->{R385} = $oops->{R384}; $oops->{R386} = \$oops->{A500}; $oops->commit;
SQL queries require a bunch of joins to link data structures together. Here are some examples.
SELECT Foobar WHERE $Foobar->{xyz} = 'abc'
SELECT object.id FROM object, attribute WHERE object.class = 'Foobar' AND object.id = attribute.id AND object.otype = 'H' AND attribute.pkey = 'xyz' AND attribute.pval = 'abc' AND attribute.ptype = '0'
SELECT Foobar WHERE ${$Foobar->{xyz}} = 'abc'
This example should show why an automatic translator would be a good idea...
SELECT ohash.object FROM object AS ohash, attribute AS ahash, object AS oref, attribute AS aref, attribute AS target WHERE ohash.class = 'Foobar' AND ohash.otype = 'H' AND ahash.id = ohash.id AND ahash.pkey = 'xyz' AND ahash.ptype = 'R' AND oref.id = ahash.pval AND oref.otype = 'S' # this is the outer ref AND oref.id = aref.id AND aref.pval = target.pkey # here's the reference indirection AND target.pval = 'abc' AND target.ptype = '0'
If you construct a query like these examples that return object id's, then use $object = $oops->load_object($id) to load them into memory.
$object = $oops->load_object($id)
I recommend that hand-written queries be read-only as there are additional columns that must be kept consistent. For example, the object table includes a reference count column to handle garbage collection of the persistent data.
The regression test suite empties and re-creates the persistent store over and over again. To prevent the accidental erasure of production data, all of the tests require a special environment variable to be set $OOPSTEST_DSN. This variable replaces the normal $DBI_DSN or $OOPS_DSN. Correspondingly there is a $OOPSTEST_USER, $OOPSTEST_PASS, and $OOPSTEST_PREFIX.
$OOPSTEST_DSN
$DBI_DSN
$OOPS_DSN
$OOPSTEST_USER
$OOPSTEST_PASS
Set these variables to something different than what you use for your production data!
Most of the tests take a long time to run and are disabled by default. If you can run the full suite in less than six hours please tell me about your configuration.
Beware mysql logging. On Debian unstable, the default configuration for mysql logs every SQL statement. Running the test suite to completion will generate several gigabytes of log file. Running out of disk space will cause the tests to fail. On DragonflyBSD (FreeBSD 4.9) the default mysql configuration includes making replication master logs.
There are a number of other modules that make perl objects persistent. For each module, I'll provide a sentence or two that explains why I wrote OOPS rather than using that one.
OOPS does not require any schema definition. Most other persistence package requires schema definition and allows the nature of the underlying RDBMS to show in both the kinds of objects you can use and how you use them. OOPS tries to let you work with perl objects without concerning yourself about how they'll be stored persistently.
Uses Data::Dumper to serialize objects into BLOBs. Cannot handle cross-linking. No query support.
Only supports Sybase. Uses a fixed schema defined in XML.
Objects are HASHes, values are scalars only (except sometimes when using the LDAP backend). No nesting. Auto-discovers keys from database columns. Has hooks for DBI, LDAP, and custom backends.
Thin layer on top of DBI. Removes much pain from using DBI. Does not change basic relationship to data -- still relational.
Uses Storable to preserve objects in files. No query support. No cross-linking. Lightweight. Transactions.
Must define schema and relationships to RDBMS. Accessor methods. Doesn't support many2many. Close tie to underlying RDBMS.
Must define schema and relationships as relates to RDBMS. Close tie to underlying RDBMS. Can help create RDBMS schema. Complex. Can cache database rows.
Must define schema. RDBMS schema is created from perl schema. Can automatically follow references (T2).
Must define schema in package files. RDBMS schema is created from perl schema. Operations are straightforward mappings to SQL.
DBM::Deep handles deep and cross-linked data. It does not have support for queries or transactions.
Less transparent. Requires user to remember a cookie to retrieve objects. Cannot handle cross-linking of objects? No query support?
Uses Data::Dumper or Storable or such to serialize objects and store them as strings. Lock granularity is the whole file. No query support. Only one (or two with MLDBM::Easy) level of access is automated.
Proprietary. Not as transparent as OOPS.
http://poop.sourceforge.net/ has an overview of options.
This software is available with and without the GPL: please write if you need a non-GPL license. All submissions of patches must come with a copyright grant so that David Sharnoff remains able to change the license on OOPS as he sees fit.
Copyright(C) 2004-2006 David Muir Sharnoff <muir@idiom.com>
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
To install OOPS, copy and paste the appropriate command in to your terminal.
cpanm
cpanm OOPS
CPAN shell
perl -MCPAN -e shell install OOPS
For more information on module installation, please visit the detailed CPAN module installation guide.