php-general Digest 4 Mar 2006 13:21:56 -0000 Issue 3997
Topics (messages 231429 through 231446):
Re: CLI utility
231429 by: Kevin Kinsey
231430 by: Ray Cantwell
231431 by: Kevin Kinsey
Re: Mysql Rows
231432 by: benifactor
231439 by: Murray . PlanetThoughtful
231440 by: Anthony Ettinger
231443 by: Murray . PlanetThoughtful
231444 by: Anthony Ettinger
231445 by: Murray . PlanetThoughtful
231446 by: Miles Thompson
Re: APC and PHP 5.1.2
231433 by: Rasmus Lerdorf
Is it better to return a multi-array, or an array of objects?
231434 by: Daevid Vincent
231435 by: chris smith
231437 by: Murray . PlanetThoughtful
231438 by: Manuel Lemos
231442 by: Daevid Vincent
Re: LDAP confusion
231436 by: chris smith
Re: Coding Practice: Use global $var or pass in by refernce
231441 by: Paul Scott
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
php-general@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
John Nichel wrote:
Ray Cantwell wrote:
Hello again,
I was wondering if any of you knew of a good command line
utility for php5 on linux? The box i write on has no X-windows.
Ray.
A command line utility to do what?
Indeed. Context might even indicate he's looking for
something to use to write his PHP scripts on a box
with no GUI.
In which case, the question is better avoided as it's
a terribly effective magnet for holy war.
Furthermore, I didn't choose the .sig below, it's randomly
generated by fortune(6), but it really speaks to me, heh....
KDK
PS. "ed(1) is the standa...." .... nah. ;-)
--
Uncle Ed's Rule of Thumb:
Never use your thumb for a rule.
You'll either hit it with a hammer or get a splinter in it.
--- End Message ---
--- Begin Message ---
Indeed i am looking for a tool to write my code with on a box that has
no gui environment, However if a Jihad is going to ensue because of it,
i shall withdraw my question, head bowed.
RTC
Kevin Kinsey wrote:
John Nichel wrote:
Ray Cantwell wrote:
Hello again,
I was wondering if any of you knew of a good command line
utility for php5 on linux? The box i write on has no X-windows.
Ray.
A command line utility to do what?
Indeed. Context might even indicate he's looking for
something to use to write his PHP scripts on a box
with no GUI.
In which case, the question is better avoided as it's
a terribly effective magnet for holy war.
Furthermore, I didn't choose the .sig below, it's randomly
generated by fortune(6), but it really speaks to me, heh....
KDK
PS. "ed(1) is the standa...." .... nah. ;-)
--- End Message ---
--- Begin Message ---
Ray Cantwell wrote:
Indeed i am looking for a tool to write my code with on a box that has
no gui
environment, However if a Jihad is going to ensue because of it, i
shall withdraw
my question, head bowed.
RTC
<context snipped in froward violation of common sense>
Well, kudos to you for discretion, which has been noted
as 'the better part of valor', indeed.
For our mutual edification, here are a few links relevant
to the discussion as it pertains to PHP in particular, from
a favorite forum of mine.
The classic:
http://www.phpbuilder.com/board/showthread.php?t=10209798
The imitators:
http://www.phpbuilder.com/board/showthread.php?t=10280025
http://www.phpbuilder.com/board/showthread.php?t=10274550 (GPL version)
http://www.phpbuilder.com/board/showthread.php?t=10255309
http://www.phpbuilder.com/board/showthread.php?t=10253439
http://www.phpbuilder.com/board/showthread.php?t=10298665
http://www.phpbuilder.com/board/showthread.php?t=10256359
Regarding WYSIWYG editors:
http://www.phpbuilder.com/board/showthread.php?t=10264772
For the Mac user:
http://www.phpbuilder.com/board/showthread.php?t=10297539
I'd also recommend plugging such terms as "editor", "text editor",
"PHP IDE" and so on into a good search engine.
Finally, try reading this:
http://en.wikipedia.org/wiki/Editor_wars
--- for some background on why this question is so, um, politically
incorrect <?> (ahem), and try Googling the phrase "vi versus emacs"
to see that it's actually true.
Meanwhile, I'm off to unwedge my tongue, which seems to have
lodged itself firmly between my cheek and upper jaw....
Use what you want, they'll make more,
Kevin Kinsey
--
A wise man can see more from the bottom
of a well than a fool can from a mountain top.
--- End Message ---
--- Begin Message ---
thank you. the table does have and id feild that auto increments, however if
you delete a user there will be a gap between the users between which would
not be what is not acurate enough. thank you for you help. simple fix. i
should have caught it.
----- Original Message -----
From: "Anthony Ettinger" <[EMAIL PROTECTED]>
To: "benifactor" <[EMAIL PROTECTED]>
Cc: "php" <php-general@lists.php.net>
Sent: Friday, March 03, 2006 3:52 PM
Subject: Re: [PHP] Mysql Rows
define $1 = 0 outside your loop.
i'm curious why you are relying on row-order in the database?
Typically you'd have a PRIMARY KEY auto_increment for something like
this.
On 3/3/06, benifactor <[EMAIL PROTECTED]> wrote:
> i need to find a way to find out what number of a row is in a database...
>
> for example:
>
> //this is the database
> Username: Chuck Password: adsasa
> Username: jimmy Password: adsf
> Username: stewart Password: dfds
>
> the information i need is what row jimmy resides on..
>
> this is what i tried:
>
> function i_gun ($user) {
> global $username;
> $gun = mysql_query("select * from users");
> while ($d = mysql_fetch_array($gun)) {
> while($d[username] != $user) {
> $i = $i + 1;
> }
> }
> }
>
> but it always returns 1. can sombody tell me what i am doing wrong or
point me in the right direction in the manual? plase and thank you
>
--
Anthony Ettinger
Signature: http://chovy.dyndns.org/hcard.html
--- End Message ---
--- Begin Message ---
On 4/03/2006 2:49 PM, benifactor wrote:
thank you. the table does have and id feild that auto increments, however if
you delete a user there will be a gap between the users between which would
not be what is not acurate enough. thank you for you help. simple fix. i
should have caught it.
----- Original Message -----
From: "Anthony Ettinger" <[EMAIL PROTECTED]>
To: "benifactor" <[EMAIL PROTECTED]>
Cc: "php" <php-general@lists.php.net>
Sent: Friday, March 03, 2006 3:52 PM
Subject: Re: [PHP] Mysql Rows
define $1 = 0 outside your loop.
i'm curious why you are relying on row-order in the database?
Typically you'd have a PRIMARY KEY auto_increment for something like
this.
I have to agree with Anthony - why are you using row order to determine
something relating to users? I couldn't follow your brief explanation
above, and the fact that you're doing it sets off some soft alarm bells
about the design of your application. Why is it important that there
shouldn't be any 'gaps' between users? Because you want to know how many
users there are? If so, simply do a SELECT COUNT(*) on the table
whenever / wherever you need to know.
If you're using it for IDs for the users, it's generally a bad idea to
reuse this type of information. If you have some other purpose, I'm
extremely curious about what it might be.
Much warmth,
planetthoughtful
---
"Lost in thought"
http://www.planetthoughtful.org
--- End Message ---
--- Begin Message ---
On 3/3/06, Murray @ PlanetThoughtful <[EMAIL PROTECTED]> wrote:
> On 4/03/2006 2:49 PM, benifactor wrote:
> > thank you. the table does have and id feild that auto increments, however if
> > you delete a user there will be a gap between the users between which would
> > not be what is not acurate enough. thank you for you help. simple fix. i
> > should have caught it.
> > ----- Original Message -----
> > From: "Anthony Ettinger" <[EMAIL PROTECTED]>
> > To: "benifactor" <[EMAIL PROTECTED]>
> > Cc: "php" <php-general@lists.php.net>
> > Sent: Friday, March 03, 2006 3:52 PM
> > Subject: Re: [PHP] Mysql Rows
> >
> >
> > define $1 = 0 outside your loop.
> >
> > i'm curious why you are relying on row-order in the database?
> > Typically you'd have a PRIMARY KEY auto_increment for something like
> > this.
> >
> >
>
> I have to agree with Anthony - why are you using row order to determine
> something relating to users? I couldn't follow your brief explanation
> above, and the fact that you're doing it sets off some soft alarm bells
> about the design of your application. Why is it important that there
> shouldn't be any 'gaps' between users? Because you want to know how many
> users there are? If so, simply do a SELECT COUNT(*) on the table
> whenever / wherever you need to know.
>
> If you're using it for IDs for the users, it's generally a bad idea to
> reuse this type of information. If you have some other purpose, I'm
> extremely curious about what it might be.
>
> Much warmth,
>
> planetthoughtful
> ---
> "Lost in thought"
> http://www.planetthoughtful.org
>
>
What I was getting at is you get the unique id for the username (if
you allow username changes, then you want a unique key to do your
joins on from other tables).
--
Anthony Ettinger
Signature: http://chovy.dyndns.org/hcard.html
--- End Message ---
--- Begin Message ---
I have to agree with Anthony - why are you using row order to determine
something relating to users? I couldn't follow your brief explanation
above, and the fact that you're doing it sets off some soft alarm bells
about the design of your application. Why is it important that there
shouldn't be any 'gaps' between users? Because you want to know how many
users there are? If so, simply do a SELECT COUNT(*) on the table
whenever / wherever you need to know.
If you're using it for IDs for the users, it's generally a bad idea to
reuse this type of information. If you have some other purpose, I'm
extremely curious about what it might be.
What I was getting at is you get the unique id for the username (if
you allow username changes, then you want a unique key to do your
joins on from other tables).
Yep, that's one good reason among many for using unique ids. Thinking a
little about the OP's question, I could understand row order being
relevant in certain situations where you wanted to display something
like, "You were the 432nd person to register at our site!", etc.
But, too often I've seen people new to database design not liking 'gaps'
because 'user1' will have a unique id of '1', while 'user2' will have a
unique id of '6' because the records associated with unique ids '2'
through '5' were deleted during testing, and so on. So, they feel that
'user2' should have a unique id of '2', ignoring the fact that that's
not a unique id at all, if you had id '2' associated with another record
at some point.
I'm not suggesting this is what the OP is doing, just that that's why I
was curious about the purpose.
Much warmth,
planetthoughtful
---
"Lost in thought"
http://www.planetthoughtful.org
--- End Message ---
--- Begin Message ---
On 3/3/06, Murray @ PlanetThoughtful <[EMAIL PROTECTED]> wrote:
>
> >
> >> I have to agree with Anthony - why are you using row order to determine
> >> something relating to users? I couldn't follow your brief explanation
> >> above, and the fact that you're doing it sets off some soft alarm bells
> >> about the design of your application. Why is it important that there
> >> shouldn't be any 'gaps' between users? Because you want to know how
> many
> >> users there are? If so, simply do a SELECT COUNT(*) on the table
> >> whenever / wherever you need to know.
> >>
> >> If you're using it for IDs for the users, it's generally a bad idea to
> >> reuse this type of information. If you have some other purpose, I'm
> >> extremely curious about what it might be.
> >>
> >
> >
> > What I was getting at is you get the unique id for the username (if
> > you allow username changes, then you want a unique key to do your
> > joins on from other tables).
> >
> >
>
> Yep, that's one good reason among many for using unique ids. Thinking a
> little about the OP's question, I could understand row order being
> relevant in certain situations where you wanted to display something
> like, "You were the 432nd person to register at our site!", etc.
I'd do this with a timestamp, and then sorting by date and doing a count()
on the results. But then again that's just me. I remember the days where i'd
clear a database after testing to keep the auto_increment inline, but
eventually, you will get out of sync on that, so it's not a reliable way of
keeping a numerical sequence.
But, too often I've seen people new to database design not liking 'gaps'
> because 'user1' will have a unique id of '1', while 'user2' will have a
> unique id of '6' because the records associated with unique ids '2'
> through '5' were deleted during testing, and so on. So, they feel that
> 'user2' should have a unique id of '2', ignoring the fact that that's
> not a unique id at all, if you had id '2' associated with another record
> at some point.
>
> I'm not suggesting this is what the OP is doing, just that that's why I
> was curious about the purpose.
>
> Much warmth,
>
> planetthoughtful
> ---
> "Lost in thought"
> http://www.planetthoughtful.org
>
>
--
Anthony Ettinger
Signature: http://chovy.dyndns.org/hcard.html
--- End Message ---
--- Begin Message ---
On 4/03/2006 5:36 PM, Anthony Ettinger wrote:
Yep, that's one good reason among many for using unique ids.
Thinking a
little about the OP's question, I could understand row order being
relevant in certain situations where you wanted to display something
like, "You were the 432nd person to register at our site!", etc.
I'd do this with a timestamp, and then sorting by date and doing a
count() on the results. But then again that's just me. I remember the
days where i'd clear a database after testing to keep the
auto_increment inline, but eventually, you will get out of sync on
that, so it's not a reliable way of keeping a numerical sequence.
Right, or you could just as easily do the same sort and WHERE clause by
your unique id, but even just doing a count, you're interested in the
fact that the record is at position <whatever> in that recordset, so
'row order' is relevant and, in that context, meaningful.
Much warmth,
planetthoughtful
---
"Lost in thought"
http://www.planetthoughtful.org
--- End Message ---
--- Begin Message ---
I hope the following will be helpful, and it is a bit of a rant ..
<rant>
The row number DOES NOT MATTER and is absolutely irrelevant. MySQL is a
relational database from which information is gathered by means of
comparing fields to key values. Even if you are using an auto-incremented
primary key it serves ONLY AS A LABEL to UNIQUELY identify each row.
If you need sequential numbers, as for membership, devise a script to
manage them and recycle them, if that's what you want.
For the number of returned rows, check mysql_row_count (or similar function).
Recognize that an ORDER BY condition will change the apparent row number.
</rant>
I am v. curious as to why you need to know which row is used for jimmy.
Regards - Miles
At 07:51 PM 3/3/2006, benifactor wrote:
i need to find a way to find out what number of a row is in a database...
for example:
//this is the database
Username: Chuck Password: adsasa
Username: jimmy Password: adsf
Username: stewart Password: dfds
the information i need is what row jimmy resides on..
this is what i tried:
function i_gun ($user) {
global $username;
$gun = mysql_query("select * from users");
while ($d = mysql_fetch_array($gun)) {
while($d[username] != $user) {
$i = $i + 1;
}
}
}
but it always returns 1. can sombody tell me what i am doing wrong or
point me in the right direction in the manual? plase and thank you
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.1.375 / Virus Database: 268.1.2/274 - Release Date: 3/3/2006
--- End Message ---
--- Begin Message ---
Jens Kleikamp wrote:
steve wrote:
Thanks for that! It meant that I should look in other directions which
helped me figure out the problem. Can you try again with:
apc.optimization=1
Your script also seems to work on my sytem with optimization=1.
The optimizer doesn't work very well at this point. It will get some
attention soon I hope.
If you need to squeeze every bit of performance out of your code there
are usually much bigger wins than an optimizer will give you in going
through and cleaning things up. The easy list of low-hanging
optimization fruit are:
1. Check your include_path and your includes. If you make heavy use of
files in a directory on your include_path, make sure that path is
first. And yes, that means before "." as well. In fact I wouldn't
even put "." in your include_path, just use
include './file.php';
if you want to include from the current directory or relative to
the current directory. You are going to save quite a few stat calls
by cleaning this up.
2. Minimize your use of include_once/require_once. If you can clean
up your dependencies and your include tree such that there is no
question of double-inclusion anywhere everything will be much
happier. A redundant include is obviously going to waste useless
cycles, but even if you don't hit the redundant case, the _once
operations are optimized for the non-cached scenario and actually
calls open() on every file which makes sense without an opcode cache
because you are going to need the file opened, but with a cache you
are going to get the opcodes from the cache and this becomes a
useless extra open() syscall.
3. Try to avoid pushing things out of the compiler and into the
executor. That's a bit cryptic, but it basically means try to
avoid dynamically defining functions and classes.
Good: <?php class foo { ... } ?>
Bad: <?php
if($some_condition) {
class foo { ... }
}
?>
In the second case the foo class has to be defined at script runtime
which is much slower than if it is unconditionally defined in the
compiler. Without an opcode cache this isn't much of an issue, of
course since you have to run both stages, but with an opcode cache
where you skip the compile phase and just feed the opcodes straight
to the executor, the more you can handle when you compile the opcodes
the faster your script will run because the executor has less work to
do.
4. Make use of APC's apc_store/apc_fetch mechanism. If you have any
sort of large array of data you need often, stick it in shared memory
with an apc_store() call. For example, a typical thing you see in
PHP applications is some sort of config.php file. It might look
like this:
<?php
$config['db_type'] = 'mysql';
$config['db_user'] = 'bob';
$config['db_pswd'] = 'foobar';
$config['data_dir'] = '/var/www/app_data';
...
?>
And then on every page you have: include './config.php';
This is very inefficient even though the actual file will be cached
in the opcode cache, it still has to execute and create the array.
You can cache the created array like this:
if(!$config = apc_fetch('config')) {
include './config.php';
apc_store('config',$config);
}
Here we only include the config file and thus create the $config
array if it isn't in the cache. So this will only happen on the
very first request. From then on it will get pulled from the
shared memory cache.
If you look around there are usually a couple of candidates for
this sort of caching in every application and it can make quite
a difference for large arrays. Try to avoid caching objects
because they need to be serialized and unserialized in and out
of the cache and you can only cache the properties anyway, so
pull the data you want to cache into an array and cache that.
-Rasmus
--- End Message ---
--- Begin Message ---
I'm building a fairly large project. I've been trying to follow best
practices, but I'm a bit worried about performance. Using PHP 5.1 and mySQL
5.0.
I have product and company classes.
So when a user does a search of the database, is it better/faster/etc. to
return just a two dimensional associative array to populate an HTML table of
the results like: product name, product id, price, company name, company
phone, etc. (assume I'm only showing some of the total number of fields).
Or, should my SQL method return me an array of product objects, which then
inturn contain a company object? Keeping in mind, these objects are then a
complete snapshot of the database row they represent, along with other
fields and such that are created upon instantiation.
Does this make sense what I'm asking?
Are these things negligible?
Does it matter that I'm only showing say 10 fields of perhaps 50 or more
possible ones (that the classes and database would hold)?
My gut feeling is to use an array as it seems less overhead and "faster".
However the object versions seems to be more expandable and maintainable
perhaps. Although a bit more work due to all the method calls to pull out
the stuff to display in the HTML.
I could run timing tests, etc, but I only have like 10 products right now in
the database while I'm building, and without REAL world data, I think my
tests will be skewed.
Lets say that I expect several thousands to a hundred thousand or so people
searching the database via the web UI when this is finally completed.
ÐÆ5ÏÐ
--- End Message ---
--- Begin Message ---
On 3/4/06, Daevid Vincent <[EMAIL PROTECTED]> wrote:
> I'm building a fairly large project. I've been trying to follow best
> practices, but I'm a bit worried about performance. Using PHP 5.1 and mySQL
> 5.0.
>
> I have product and company classes.
>
> So when a user does a search of the database, is it better/faster/etc. to
> return just a two dimensional associative array to populate an HTML table of
> the results like: product name, product id, price, company name, company
> phone, etc. (assume I'm only showing some of the total number of fields).
>
> Or, should my SQL method return me an array of product objects, which then
> inturn contain a company object? Keeping in mind, these objects are then a
> complete snapshot of the database row they represent, along with other
> fields and such that are created upon instantiation.
>
> Does this make sense what I'm asking?
>
> Are these things negligible?
>
> Does it matter that I'm only showing say 10 fields of perhaps 50 or more
> possible ones (that the classes and database would hold)?
>
> My gut feeling is to use an array as it seems less overhead and "faster".
> However the object versions seems to be more expandable and maintainable
> perhaps. Although a bit more work due to all the method calls to pull out
> the stuff to display in the HTML.
>
> I could run timing tests, etc, but I only have like 10 products right now in
> the database while I'm building, and without REAL world data, I think my
> tests will be skewed.
>
> Lets say that I expect several thousands to a hundred thousand or so people
> searching the database via the web UI when this is finally completed.
I don't think you'll find much difference either way.. I wouldn't
return a whole object though - lots of memory usage there for a small
result set.
If you return an array of data, you have to firstly turn the results
into an array, then after you return it you have to go through the
array again to display the results.. so you're doubling up a little.
Then again - it depends on how your app is set up. Personally I use my
own API to fetch data so it returns an array, then the "front" can do
whatever with it (display html, display xml - doesn't matter to the
API).
--- End Message ---
--- Begin Message ---
On 4/03/2006 3:10 PM, Daevid Vincent wrote:
I'm building a fairly large project. I've been trying to follow best
practices, but I'm a bit worried about performance. Using PHP 5.1 and mySQL
5.0.
I have product and company classes.
So when a user does a search of the database, is it better/faster/etc. to
return just a two dimensional associative array to populate an HTML table of
the results like: product name, product id, price, company name, company
phone, etc. (assume I'm only showing some of the total number of fields).
[snip]
One observation: you shouldn't return all fields in a recordset unless
you *need* all of the fields in a recordset.
The majority of the time, you should be explicitly stating which fields
to retrieve in your SQL statement, as in:
SELECT field1, field2, field8 FROM mytable WHERE <whatever>
as opposed to:
SELECT * FROM mytable WHERE <whatever>
Some of the time, yes, that will mean you're explicitly typing out 7
field names from a table that only has 8 field names, but getting out of
the habit of using "*", particularly if you expect your application to
work well under heavy loads, will save you resources, which will
increase your app's overall performance.
It may be you're already doing this, but it wasn't clear from your post.
Much warmth,
planetthoughtful
---
"Lost in thought"
http://www.planetthoughtful.org
--- End Message ---
--- Begin Message ---
Hello,
on 03/04/2006 02:10 AM Daevid Vincent said the following:
> Does it matter that I'm only showing say 10 fields of perhaps 50 or more
> possible ones (that the classes and database would hold)?
>
> My gut feeling is to use an array as it seems less overhead and "faster".
> However the object versions seems to be more expandable and maintainable
> perhaps. Although a bit more work due to all the method calls to pull out
> the stuff to display in the HTML.
Obviously retrieving arrays with only the fields of the objects you need
is the fastest way.
--
Regards,
Manuel Lemos
Metastorage - Data object relational mapping layer generator
http://www.metastorage.net/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/
--- End Message ---
--- Begin Message ---
> SELECT field1, field2, field8 FROM mytable WHERE <whatever>
>
> as opposed to:
>
> SELECT * FROM mytable WHERE <whatever>
>
> It may be you're already doing this, but it wasn't clear from your post.
Yes, Murray, thank you, and I am already doing this. :)
--- End Message ---
--- Begin Message ---
On 3/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> [snip] I vaguely recall you couldn't do an anonymous bind to an active
> directory system - you had to properly authenticate before you could do
> a search.
>
> You didn't include the bind stuff so I can't tell if that's the problem
> :)
> [/snip]
>
> I thought that I was not doing an anonymous bind, until I changed the
> username to something that I know did not exist. The bind occurred (or
> appeared to) anyhow.
>
> if(!$ds=ldap_connect("foo")){
> echo "did not connect";
> }else {
> echo "connection successful";
> }
> $un = "user";
> $upw = "pass";
> echo "connect result is " . $ds . "<br />";
> ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3);
> ldap_set_option($ds, LDAP_OPT_REFERRALS, 0);
>
> if ($ds) {
> echo "Binding ...";
> if(!$r=ldap_bind($ds, $un, $upd)){
> echo "unable to verify</br>";
> }else{
> echo "verified<br>";
> }
>
> The result is always "verified".
>From the comments on www.php.net/ldap_bind:
I have found that if either of the valuse for user or password are
blank, or as in my case a typo resulted in a blank user as it was an
undefined variable, the ldap_bind() will just perform an anonymous
bind and return true!
You have:
$upw = "pass";
but using $upd in ldap_bind ...
if(!$r=ldap_bind($ds, $un, $upd)){
unless it's a typo in your example that could explain it. ?
--- End Message ---
--- Begin Message ---
On Fri, 2006-03-03 at 16:19 -0500, tedd wrote:
> Perhaps I'm fortunate, but I usually find a way around using Globals.
> And since I've been coding in PHP, I've never been forced to use them.
>
Just my 2c...
In our framework, I use globals as well, although I do tend to agree
with Tedd regarding workarounds rather... :)
Something like so:
I create a global to hold the db object (in my case MDB2 or PEAR DB) and
then use a loadclass function to get the dbconfig from another module.
This creates a nice way to easily pick it up wherever its needed. I then
use the factory method to instantiate the db abstraction layer and pass
it, through my "engine class" to an "object class" where I further
abstract the db functions through a central db class. All of the modules
in the system that have database derived classes extend my dbTable
class, thereby keeping everything centralised.
In dbTable class, I evaluate if the db object exists, and if it *really*
doesn't, I create it through the engine. This makes for "lazy"
evaluation of the db object, so that it works kinda on demand, rather
than on every request.
Using this method, I can also use a global error callback method to
handle _all_ database errors gracefully, using PEAR_Error. I do think
that there may be a slight performance hit doing it this way, but in an
app with over 180 000 lines of code (so far) I find it works just
fine...
--Paul
--- End Message ---
