Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^3: Class::HPLOO, attributes and object persistence for OODB.

by adrianh (Chancellor)
on Feb 09, 2004 at 14:53 UTC ( [id://327639]=note: print w/replies, xml ) Need Help??


in reply to Re: Re: Class::HPLOO, attributes and object persistence for OODB.
in thread Class::HPLOO - Need advice in attributes and object persistence for OODB.

Since in your original post your request for advice appeared in the very last sentence of the post, and you have a history of making regular (to me) annoying announcements of your module it's an understandable mistake. I certainly ignored your OP completely when it first appeared.

The idea of the attributes, is to give a type to them and the setter and getter methods.

Having to type attributes seems both unnecessary and un-perlish to me.

Soo, with a method to access or set the attributes we can know when they are changed or not, soo will be possible to define if an object is "dirty" or "clean", needed to make the persistent proxy system.

That's one approach. There are, of course, others (e.g. taking a hash of all the key/values at save time and using that as a comparison point, implementing the object on top of a tied hash that tracks changes, etc.)

The DB communication will be made through HDB

As a general point I think your module naming strategies suck - HPL and H prefixes mean nothing to to the world in general. Descriptive names help.

With HDB we don't use SQL, or don't need to use, to work with the DB, we just use commands and syntax based in Perl it self. Soo, we can work with any type of DB without need to care with the nuances of each SQL or behavior of each DB type. Soo, the persistence system will work in any DB, from SQLIte to MySQL and Oracle.

I would recommend using one of the many existing systems out there that do this sort of thing rather than reinventing another wheel.

But "Prevayler" use a log persistence system, soo it doesn't use DB, just a log with all the commands send to an object.

That's not really the way Prevayler is used. The log files are for backup. Prevayler uses RAM as its persistence layer. In an environment using Prevayler in the way it is intended you'd only hit the log files when the machines go down or (maybe - this bit is still under development AFAIK) replication . See the Prevalence FAQ and various articles for more info.

But for a true persistent system, that works in different processes, different machines and for big systems, it really need to be made with a true DB.

That's not true. Many big systems don't use 'true DB' based persistance layers. It depends on what your requirements are. I've got several large live projects that are happily using Storable and Cache::Cache for their persistent layers with no trouble at all.

For example, in Perl we don't have the "implements" resource for classes.

You could either have an abstract base class, or just have the class that will be using the object use duck typing to figure out whether the object has the methods you're interested in.

But with just an "extends" system it won't work too, since the persistence system need to change the setter and getter methods, also inserting "mask/layer" classes (proxy) when an object has some association with other object.

This, of course, depends on the details of how your persistence layer operates. In many case syncing to the database on every set/get is counter productive. Even if you do you can still use a base class. You can have the base class generate the setters/getters for example (e.g. Class::DBI) or, as I said earlier, use a tied hash as the base object type.

Soo, before start to work on that, I'm just asking for some opinion from the monks about the persistence system and the new attribute definition.

First, spend some time reading http://poop.sourceforge.net/ - a long list of Perl modules that do similar things to what it sounds like you want. Then take a long look at all of the modules it mentions.

Next spend some time on CPAN looking at the newer modules that aren't on the current POOP list (e.g. Class::Tables).

Then take a deep breath and consider whether one of these well documented and supported solutions will do what you want already. If so go use it and feel happy at all the time and effort you saved.

If no module does exactly what you want, spend some time thinking about whether this could be solved by a redesign of your application. Would your time be better spent migrating your application so it can use an existing supported and documented framework?

If you can't do this write down the new features that you need. Would it be sensible to add these to an existing framework rather than re-implement everything from scratch?

If you cannot add what you want to an existing framework then think about writing your own persistence layer. A useful tool I have found to discover whether you have reached this stage is that you should be able to write a short description of why a particular user should or should not use your module ("Use Class::DBI when foo, use SPOPS when bar, use Class::HPLOOK when ???").

Also consider whether separating the concerns of Class::HPLOO (some syntactic sugar for class creation) and object persistence into separate modules might not be an entirely bad idea.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (7)
As of 2024-03-28 11:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found