Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: OO Perl & RDBMS Strategy Question

by snellm (Monk)
on Aug 30, 2002 at 14:03 UTC ( [id://194113]=note: print w/replies, xml ) Need Help??


in reply to OO Perl & RDBMS Strategy Question

My usual apprach is to have value objects that can be loaded or saved to a datastore, ie:

$datastore->beginTransaction(); my $person = $datastore->getPersonById($personid); ...manipulate $person... $datastore->store($person); $datastore->commitTransaction();

The main advantages of this is:

  • Simplicity: The CRUD approach (Create, Retrieve, Update, Delete) is well understood and aligns well with SQL
  • Performance: Access to the datastore is kept to a minimum
  • Modularity: The datastore is decoupled from the value objects

I feel it's usually best to leave transaction management to the datastore, rather than trying to hack together something yourself.

-- Michael Snell
-- michael@snell.com

Replies are listed 'Best First'.
Re: OO Perl & RDBMS Strategy Question
by prodevel (Scribe) on Aug 31, 2002 at 04:33 UTC
    Just so that everyone is aware, Oracle has an pseudo-column, "rowid", which is select-able and is unique to any given row in the database. If that psuedo-column is selected upon the edit of the row and thus the original value(s) comapared after any changes, the editing user may be rejected, warned or given the option to save changes.

      And in PostgreSQL you can do that with xmin and ctid. xmin holds the last transaction id to update/update the row and ctid holds the physical location of the tuple in the table. If you use these then you've got to do it with full knowledge of PostgreSQL's multiversion concurrency control and how that affects which tuples are visible when. You can augment that with the ctid = currtid(tableoid, ctid) function which will return the current valid ctid even if your known ctid is old. It also happens that if you can locate a record by ctid then you get lightning fast access since PostgreSQL knows exactly where to seek in the table to find it. I was writing some initial code to use this feature where multiple identity values were used a fallbacks: first ctid, then app object id or whatever else is normally used for identity.

      __SIG__
      printf "You are here %08x\n", unpack "L!", unpack "P4", pack "L!", B::svref_2object(sub{})->OUTSIDE

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://194113]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (6)
As of 2024-04-23 15:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found