Re: how does one trap for out-of-memory errors?
From: lawrence (lkrubner_at_geocities.com)
Date: 10/26/03
- Next message: daniel: "Sessions and objects"
- Previous message: daniel: "PHP & Javascript problem"
- In reply to: Nikolai Chuvakhin: "Re: how does one trap for out-of-memory errors?"
- Next in thread: Nikolai Chuvakhin: "Re: how does one trap for out-of-memory errors?"
- Reply: Nikolai Chuvakhin: "Re: how does one trap for out-of-memory errors?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 26 Oct 2003 12:51:44 -0800
nc@iname.com (Nikolai Chuvakhin) wrote in message news:<32d7a63c.0310251605.258cfb2b@posting.google.com>...
> lkrubner@geocities.com (lawrence) wrote
> in message <da7e68e8.0310241718.3fcdc191@posting.google.com>:
> >
> > I am putting database returns in PHP arrays to mask the client
> > code from the underlying database. That is, I don't want my code
> > to know what kind of database or datastore is being dealt with.
>
> Haven't you heard that abstraction doesn't work? :) I am not
> trying to start a flame war here, but you need to understand that
> higher level of abstraction ALWAYS implies a performance penalty.
> In your case, you are shooting for capital abstraction and what
> you get for it is the performance equivalent of capital
> punishment.
This runs counter to most of what I've been taught. I'm not sure what
you mean when you say abstraction doesn't work. Much software work
involves abstraction. You could argue that PHP itself is an
abstraction, hiding the complexity of the underlying C code. Some
might say that anything other than machine code is an abstraction. I
can't think of a software project that doesn't involve abstraction.
As for OO design, to hide the datastore seems like an obvious move.
Hasn't the team working on PEAR done the same?
>
> > I am storing all actual SQL in objects that I am calling
> > queryObjects. But the only place the query objects are called
> > is in what I call Get, Update, Delete, and Insert objects. The
> > Get, Update, Delete, and Insert objects are meant to mask, from
> > the rest of the code, what kind of database or datastore is in
> > use. In other words, if I want to get all weblog entries out of
> > a database, I might have a method called getAllWeblogEntries,
> > and this function would contain actual SQL, and return a PHP
> > array. So I might have a query object for MySql and a query
> > object for PostGre and a query object for XML streams. Each of
> > these query objects would have a method called
> > getAllWeblogEntries, and each would return a PHP array.
>
> And that's the root of your problem. You want to return something
> of potentially very large size, and you are hell-bent on storing
> it in memory.
No, I am not hell bent. I asked for alternatives.
> But let me ask you: what will the application do
> with a PHP array that contains all entries in the weblog? Output
> them? Then the entries don't have to be in memory at all, they
> can be output straight from the DB buffer. Sort them? Again,
> they don't have to be in the memory for that, you should have
> taken care of it on the database level. Search through them?
> Same thing; too late to do it efficiently, had to be done on the
> database level.
>
> So my suggestion to you is not to have a getAllWeblogEntries
> method at all. Rather, you should have a getWeblogEntry method
> that returns a single weblog entry in an array and an entriesLeft
> method that returns a boolean value. This way, you can retrieve
> all entries one by one:
>
> $qo = new queryObjectMySQL ('SELECT * FROM entries');
> // the constructor establishes the connection, retrieves data,
> // and keeps the resulting resource for the object's internal
> // use...
> while ($qo->entriesLeft ()) {
> $entry = $qo->getWeblogEntry ();
> // now, do what you want with the $entry...
> }
I think your suggestion is a good one. Somehow I must get just one
entry at a time. The query object also needs to remember which entry
it got last, so it can get the next one. The SELECT object would have
to wrap that interger and pass it along to the final code, especially
if the final code has a loop that needs to know how long it is
supposed to keep running.
Off hand, it sounds terribly complicated, and the whole of the code
would have to be rewritten. Every loop would have to be rewritten. But
it would eventually get the code free of working with dangerously
large arrays. It is a project that, I think, will take a few months,
but I think the direction you suggest is a good one.
> > I can't imagine how I can hide the database from the client code
> > if I use database return resources, as you suggest above.
>
> You make it sound like it's a good thing... :)
Well, this code is being written first to work with MySql, but I'm
supposed to write it in such a way that would make it easy to switch
to PostGre. So I've written it the way I have to save myself some
future work. And saving oneself future work is the aim of most OO
abstraction.
- Next message: daniel: "Sessions and objects"
- Previous message: daniel: "PHP & Javascript problem"
- In reply to: Nikolai Chuvakhin: "Re: how does one trap for out-of-memory errors?"
- Next in thread: Nikolai Chuvakhin: "Re: how does one trap for out-of-memory errors?"
- Reply: Nikolai Chuvakhin: "Re: how does one trap for out-of-memory errors?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
