RE: [Apc-aa-coders] getDB and freeDB

[Jakub A. <jak...@se...>]

I am not sure when PHP frees variables, perhaps on leaving a function,
surely not later than on finishing the script. This way it knows you
finished your SELECT. My suggestion is not to use "global $db" but "$db
= new DB_AA" which should be sufficient. Perhaps you could measure how
much time (if any) it takes to create a new DB_AA.
 
Jakub

-----Original Message-----
From: apc...@li...
[mailto:apc...@li...] On Behalf Of Mitra
Sent: Tuesday, February 25, 2003 4:56 AM
To: Jakub Adamek; apc...@so...
Subject: RE: [Apc-aa-coders] getDB and freeDB


Jakub, Honza

Are we happy with the way I'm suggesting to do this ?

- Mitra


At 9:03 AM +1100 18/2/03, Mitra wrote:

You could be correct, I'm not sure if PHP caches connections.


What I KNOW to be bad is using $db, $db2, and $db3 because if in the
middle of using $db to fetch records, then you use a function call (for
example to turn and id into a name) and this uses the same $db then you
break things. Its a recipe for bugs.


So I see two solutiosn


1:  $db = new DB_AA() ;    use the $db ;

or

2: $db = getDB; use the $db  ; freeDB($db)


Actually, I can't see how #1 (or the current way of doing things) can
reuse database connections, because how does PHP know when you've
finished with the SELECT?


yes - there could be a problem with "return" without freeing the db, but
I'd rather have an occasional inefficiency, than a big problem with
possible bugs. I'm not making any mass changes, just changing the code
as I work on it, so I think it will be easy to do it carefully.


- Mitra



At 8:56 PM +0100 17/2/03, Jakub Adamek wrote: 

Mitra,

the PHPlib approach of having the DB connection and recordset in one
class is a bit strange. The result is, we should create a new recordset
DB_AA for each SELECT query. The current approach of using one recordset
everywhere is perhaps caused by the name DB_AA which looks like database
and usually only one database is used. It is surely wrong.

I am not sure, but my idea was that the persistent connections are kept
by PHP and not by individual scripts and thus creating a new DB_AA would
waste no time as it uses always only finds a persisten connection? It
this is the case, getDB and freeDB are not needed because they only
duplicate this behavior.

One more remark: Your approach seems to me a bit uncovenient. The
problem is you must call freeDB() every time you exit any function.
Surely somebody will forget to do so at least in some places where he or
she uses "return". In C++ such things are solved by constructors and
destructors, but PHP has no destructors. On the other hand this will
perhaps do no much damage as the not-freed DBs will be closed as the
script finishes.

Jakub

> -----Original Message-----
> From: apc...@li...
> [mailto:apc...@li...] On Behalf Of Mitra
> Sent: Sunday, February 16, 2003 10:56 AM
> To: apc...@so...
> Subject: [Apc-aa-coders] getDB and freeDB
>
>
> One change of note is to add functions getDB and freeDB so that there
> is no longer the risk of one operation mucking up an in-process DB
> action.
>
> Basically instead of trying to decide whether to use globals $db $db2
> or $db3 instead just  go
>
>
> $db = getDB()
> $db->normal db ops
> freeDB($db)
>
> The system keeps an array of unused $db's so that we still get the
> advantages of keeping connections open.
>
> I have NOT incorporated this into the existing code, - since to do so

> would inevitably involve making one or more mistakes that broke

> something!,  but I will do whenever I'm working on something.

>

> - Mitra

>

> --

> Mitra Technology Consulting -  www.mitra.biz -
> mi...@mi... 02-6684-8096  or 0414-648-0722
>
> Life is a Mystery to be Lived, not a Problem to be Solved
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Apc-aa-coders mailing list
> Apc...@li...

> https://lists.sourceforge.net/lists/listinfo/apc-aa-coders

>



--

Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722 

Life is a Mystery to be Lived, not a Problem to be Solved



-- 
Mitra Technology Consulting -  www.mitra.biz - mi...@mi...
02-6684-8096  or 0414-648-0722 

Life is a Mystery to be Lived, not a Problem to be Solved