Re: Beginner OOP style question

Thankyou! I hardly expected such an insightful reply so quickly!

What you've said makes loads of sense. Firstly, regarding the class method, I give myself a big forehead slap, and say 'Doh' for that. I should have made that intuitive leap.

Secondly the search. Again, this makes lots of sense. I did think of this but initially discarded it, since my backend is SQL and I thought this would be costly in time and memory (each object could be several K worth of text).

But after reading your words and some reflection, I think this is mitigated by two factors:

Searches should not return that many results. A hard limit can be imposed if necessary.
Better, if I change my implementation of the 'fetch' method, which pulls from the SQL, and my AUTOLOAD proxy methods for the data, I can initialize a bunch of objects from a search, but not actual load a single byte of data from the database backend until a data method actually requests it.

This is some real work, but I think it's doable, and would be massively elegant.

BTW, just some background on my little project, may be interesting to you or others, and comments are as always welcome. I'm designing my modules to support on online journal, the 'dear diary' kind.

I have implemented this several times over the last few years, the earliest being a .BAT file and a bunch of editor macros. The most recent and still in use is a PHP version.

So to bring it into the OOP context, each 'Entry' object holds some meta information like author (probably will be another object), date written and so forth, plus the actual text.

The part that made me think it would be an ideal bench test for my OOP learning experience was that I wanted to implement a DBM backend later, to replace the SQL backend. If done right, I simply copy Backend.pm-DBM over Backend.pm and suddenly my appliction no longer needs an SQL database. I also don't need to touch Entry.pm, or any of the other modules.

This comes from a pet peeve of mine, the amount of free software out there which requires a MySQL server, yet doesn't really need one. I'd like to release something that gives the user a choice.

Anyway, that's enough raving about my project, I'm off to go and think about how to implement my load on demand Journal Entry objects.

Thanks again!

Update 2002/3/3

Both the class search method, and the on-demand fetching are both working a treat.

For the latter, basically I just renamed my fetch method to real_fetch, and made a new fetch method, which simply sets an fetch_ID field in the object.

When my AUTOLOAD proxy method gets called when something tries to access the object data, the method sees that it is necessary to fetch it, and passes the fetch_id to the real_fetch method, which goes out to the backend to do the grunt work.

Great! With the above working, the search class method can return umpteen objects back to the program, without incurring any database access for each one. As soon as the program tries to get data out of them, it is fetched automatically.

Comment on Re: Beginner OOP style question

Replies are listed 'Best First'.
(jeffa) 3Re: Beginner OOP style question by jeffa (Bishop) on Mar 02, 2002 at 13:21 UTC
"...the amount of free software out there which requires a MySQL server, yet doesn't really need one" Have you seen DBD::SQLite yet? Also, instead of simply 'copying Backend.pm-DBM over Backend.pm', why not instead subclass? Maybe something like Backend::SQL and Backend::DBD. Good luck! jeffa L-LL-L--L-LL-L--L-LL-L-- -R--R-RR-R--R-RR-R--R-RR B--B--B--B--B--B--B--B-- H---H---H---H---H---H--- (the triplet paradiddle with high-hat)	[reply]
Re: Re: Re: Beginner OOP style question by fuzzyping (Chaplain) on Mar 02, 2002 at 13:37 UTC
Please forgive me for being mildly off-topic, but I thought I might suggest an alternative for the way you're creating your search() query (using an array). I'm assuming that you're going to be opening a db connect(), running a query for matches, and returning the positives. A lot of people will tell you to let the db perform the heavy work for you. Depending on the size of the table, they may or may not be right. I recently completed a script to store logfile statistics into a MySQL db (who hasn't), and found that it's actually quicker for me to open the dbh, pull all of my data out (assuming I only need to search one field), and insert them as keys into a hash (null values). Hashes are incredible for handling massive amounts of similar data. Anyhoo, then you can perform a simple defined() or exists() on the hash keys for your search criteria (or some regex derivative thereof). My particular application dropped from a runtime of minutes, to just under 7 seconds (comparison/injection of approximately 12000 complex entries). That said, it's just my $.02. I'm not an expert, it just happened to work well for me... it may not be applicable to your needs, but maybe it will in the future. :-) *Hashes are your friend* -fuzzyping	[reply]
Re: Re: Re: Re: Beginner OOP style question by Anonymous Monk on Mar 02, 2002 at 20:49 UTC
Before doing something like this you might want to check the index structre on your database. I know this isn't really a Perl answer, but with larger data sets, such a massive scoop and throw into memory may not be a really good answer. Checking or creating an index on the key fields might be a better alternative, and more useful in the long run. just my 0.02 worth webadept.net	[reply]


Welcome to the Monastery
	PerlMonks