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

Re: OO Perl & RDBMS Strategy Question

by lachoy (Parson)
on Aug 30, 2002 at 03:55 UTC ( [id://193988]=note: print w/replies, xml ) Need Help??


in reply to OO Perl & RDBMS Strategy Question

I strongly disagree with the idea that persistent object storage should be totally transparent. Normally this translates to your first option, syncing the database on every set() method call. Even if you do a bulk set (multiple fields at once) this means you need to do the same for the get(), otherwise you've lost the goal of having each object represent what's in the database right now. It may be necessary in some scenarios but I haven't programmed in any of them, plus it's both a database and network nightmare.

Instead, push the decision on when to save back on the user of the object. Yes, having a load() (or fetch()) and save() makes serialization visible. Good! The user always knows what's being done with the object and when a save is appropriate. I've taken this tack with SPOPS and it's seemed to work well. And SPOPS has an option to refetch the data for an object from the database, in the case that you have long-lived objects.

I might as well pipe up with a tangential opinion: I don't think there should be separate 'create' and 'update' calls for objects, just a 'save'. Do you really care which is being done?

Chris
M-x auto-bs-mode

Replies are listed 'Best First'.
Re: Re: OO Perl & RDBMS Strategy Question
by djantzen (Priest) on Aug 30, 2002 at 04:40 UTC

    Giving the prerogative to save or not to the caller has the added benefit of allowing a user to play with an object and not worry about tampering with live data, which can make an API significantly safer and more useful. The drawback to this approach is that you can get into race conditions with other users manipulating the "same" object, so in some cases it may be necessary to do some kind of blocking or locking when it comes time to save your data. For example, check out the object (with a unique ID) before saving by setting a temporary semaphore file or table entry to lock the relevant table rows.

      Exactly: you need some strategy to deal with the problem of overwrites rather than designing a whole system so they don't happen. You can create a unique ID on fetch, you can have a timestamp field automatically update on an insert/update and compare them before updating the object. Plus there's always the strategy of 'last-write wins', which is a legitimate trade-off in many situations.

      Chris
      M-x auto-bs-mode

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (1)
As of 2024-07-19 17:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?
    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.