Re: [PHP] Mysqli support - test or complain? [SOLVED]
Robert Cummings wrote: I can't remember what sort of environment the OP was in, but if any sort of organised testing is done, the use of two different APIs will just about double the test-effort. Which is why I still think the best option is to mandate _one_ of the APIs and choose your hoster accordingly. Well if you write unit tests, having the unit tests applied to one or the other is the same amount of work since it just requires a switch to change between mysql and mysqli. Regardless of how you do it, it's twice the amount of work to run a test twice. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
On Dec 12, 2007 4:47 AM, Per Jessen [EMAIL PROTECTED] wrote: Robert Cummings wrote: I can't remember what sort of environment the OP was in, but if any sort of organised testing is done, the use of two different APIs will just about double the test-effort. Which is why I still think the best option is to mandate _one_ of the APIs and choose your hoster accordingly. Well if you write unit tests, having the unit tests applied to one or the other is the same amount of work since it just requires a switch to change between mysql and mysqli. Regardless of how you do it, it's twice the amount of work to run a test twice. actually its really not a big deal to actually run a test a couple of times. supporting multiple libraries will add flexibility, but always with flexibility there is the cost of additional complexity (this can take many forms). in regard to unit tests, the extra effort would be spent actually writing both unit tests. however, once the first one is written the second one should be pretty easy, especially if they are both coded against an abstract database interface. it could even make sense to write one test against an abstract class then create concrete subclasses for each specific library. then in the future adding a test for, say postgre, would be trivial. -nathan
Re: [PHP] Mysqli support - test or complain? [SOLVED]
On Wed, 2007-12-12 at 10:47 +0100, Per Jessen wrote: Robert Cummings wrote: I can't remember what sort of environment the OP was in, but if any sort of organised testing is done, the use of two different APIs will just about double the test-effort. Which is why I still think the best option is to mandate _one_ of the APIs and choose your hoster accordingly. Well if you write unit tests, having the unit tests applied to one or the other is the same amount of work since it just requires a switch to change between mysql and mysqli. Regardless of how you do it, it's twice the amount of work to run a test twice. No, it's twice the amount of time to run the test a second time. But if it's a unit test it's time you can be doing something else... or maybe when you install PHP from source you sit there and watch the unit tests run at the end? I go and do something else in another window. The whole point of unit tests is to automate testing things so that there's less work to do. Cheers, Rob. -- ... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
You use a session variable for that? Why not? That's entirely the wrong place to store something like which database API is installed. Not really. You could even wrap a function called (for example) Feature() around it. It should a class variable or global configuration variable. Heck, I'd say it's more appropriate to do extension_loaded( 'mysqli' ) on every call than to use a session variable. Why? It's very unlikely to be changing between calls. And even if it does, it's once in a blue moon. Granted though, I can't see it being a particularly intensive function call, so I can't see the harm in calling it on every invocation. -- Richard Heyes http://www.websupportsolutions.co.uk Knowledge Base and HelpDesk software that can cut the cost of online support ** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON-PROFITS ** -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
Richard Heyes wrote: You use a session variable for that? Why not? Because it's not user data, it's server data. That's entirely the wrong place to store something like which database API is installed. Not really. You could even wrap a function called (for example) Feature() around it. Yeah, really. Sessions are for user data. If it's the same for all users then it doesn't belong in the session, it belongs in a server-wide cache. It should a class variable or global configuration variable. Heck, I'd say it's more appropriate to do extension_loaded( 'mysqli' ) on every call than to use a session variable. Why? It's very unlikely to be changing between calls. And even if it does, it's once in a blue moon. Granted though, I can't see it being a particularly intensive function call, so I can't see the harm in calling it on every invocation. AFAIK a call to extension_loaded is pretty cheap, but if you really feel the need to cache it between requests the best place to store it would be in a file on the server. However, I'd expect a stat on that file will be more expensive than calling extension_loaded. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
Stut wrote: Richard Heyes wrote: You use a session variable for that? Why not? Because it's not user data, it's server data. That's entirely the wrong place to store something like which database API is installed. Not really. You could even wrap a function called (for example) Feature() around it. Yeah, really. Sessions are for user data. If it's the same for all users then it doesn't belong in the session, it belongs in a server-wide cache. It should a class variable or global configuration variable. Heck, I'd say it's more appropriate to do extension_loaded( 'mysqli' ) on every call than to use a session variable. Why? It's very unlikely to be changing between calls. And even if it does, it's once in a blue moon. Granted though, I can't see it being a particularly intensive function call, so I can't see the harm in calling it on every invocation. AFAIK a call to extension_loaded is pretty cheap, but if you really feel the need to cache it between requests the best place to store it would be in a file on the server. However, I'd expect a stat on that file will be more expensive than calling extension_loaded. the on disk file could be [re]generated automatically when the server is started up by the application and dumped onto tmpfs or even not stored as a file at all but directly in memory using apc or something similar either way I agree it's a server wide setting that is garanteed not change as long as the webserver is not restarted - atleast I can't see an extension becoming available 'just like that' ... going on the basis that dl() should be illegal ;-) - actually it is not available if your using a threaded webserver (who does?) and as of php6 not webserver SAPI implements dl() not to mention safe_mode which also disables it. -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
Stut wrote: However, I'd expect a stat on that file will be more expensive than calling extension_loaded. Difficult to say, but a stat() is cheap, especially if the inode is cached already. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
Because it's not user data, it's server data. So? It's there - use it. That's entirely the wrong place to store something like which database API is installed. Not really. You could even wrap a function called (for example) Feature() around it. Yeah, really. Sessions are for user data. If it's the same for all users then it doesn't belong in the session, it belongs in a server-wide cache. Sessions are for whatever you choose to put in them. And why implement a cache when you've got something perfectly usable (sessions) already? -- Richard Heyes http://www.websupportsolutions.co.uk Knowledge Base and HelpDesk software that can cut the cost of online support ** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON-PROFITS ** -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
Richard Heyes wrote: Because it's not user data, it's server data. So? It's there - use it. So are cookies, would you stuff this into a cookie? No, because that's not what cookies are there for. Because it's there is never a good reason to do something. That's entirely the wrong place to store something like which database API is installed. Not really. You could even wrap a function called (for example) Feature() around it. Yeah, really. Sessions are for user data. If it's the same for all users then it doesn't belong in the session, it belongs in a server-wide cache. Sessions are for whatever you choose to put in them. And why implement a cache when you've got something perfectly usable (sessions) already? You could potentially be pointlessly duplicating that data hundreds or thousands of times depending on how busy your site is. Also, in this particular example there is no need to cache that information beyond the request level because asking PHP for it is not an expensive operation, or at the very least is no more expensive than maintaining it in a session. One other thing to note is that putting it in the session will survive a rebuild of PHP to add/remove modules and a restart of the web server. It's probably not likely to happen but that could seriously break your application. However this is just my opinion. You're free to implement your application in whatever way you choose. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
On Tue, 2007-12-11 at 15:25 +, Stut wrote: Richard Heyes wrote: Because it's not user data, it's server data. So? It's there - use it. So are cookies, would you stuff this into a cookie? No, because that's not what cookies are there for. Because it's there is never a good reason to do something. That's entirely the wrong place to store something like which database API is installed. Not really. You could even wrap a function called (for example) Feature() around it. Yeah, really. Sessions are for user data. If it's the same for all users then it doesn't belong in the session, it belongs in a server-wide cache. Sessions are for whatever you choose to put in them. And why implement a cache when you've got something perfectly usable (sessions) already? Sre, sessions are for whatever you choose to put in them. That's like saying bodies are for whatever a crazed murderer chooses to put in them... the statement is true, but it's not optimal. Cheers, Rob. -- ... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
So? It's there - use it. So are cookies, would you stuff this into a cookie? No, because that's not what cookies are there for. Not because it's not what cookies are for - but because sessions are a more efficient and easier to use storage medium. You could potentially be pointlessly duplicating that data hundreds or thousands of times depending on how busy your site is. Well as always, if that's a concern then more thought would be required. But storage constraints are rarely a concern nowadays. Also, in this particular example there is no need to cache that information beyond the request level because asking PHP for it is not an expensive operation, or at the very least is no more expensive than maintaining it in a session. Granted. One other thing to note is that putting it in the session will survive a rebuild of PHP to add/remove modules and a restart of the web server. It's probably not likely to happen but that could seriously break your application. Then use the function directly. -- Richard Heyes http://www.websupportsolutions.co.uk Knowledge Base and HelpDesk software that can cut the cost of online support ** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON-PROFITS ** -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
Sre, sessions are for whatever you choose to put in them. That's like saying bodies are for whatever a crazed murderer chooses to put in them... No it's not. the statement is true, but it's not optimal. Real life is rarely optimal. -- Richard Heyes http://www.websupportsolutions.co.uk Knowledge Base and HelpDesk software that can cut the cost of online support ** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON-PROFITS ** -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
On Tue, 2007-12-11 at 16:31 +, Richard Heyes wrote: Sre, sessions are for whatever you choose to put in them. That's like saying bodies are for whatever a crazed murderer chooses to put in them... No it's not. Yes it is. Neither is a good argument. the statement is true, but it's not optimal. Real life is rarely optimal. That's not a valid excuse for taking the sloppy pig route to development. Sloppy pig's give conscientious developers a bad name. And when they use PHP to create their slop, they give PHP a bad name. You would think you would lean towards conscientiousness since you use an email address with phpguru in it. But I guess anyone can claim whatever they want... it doesn't make it true. Maybe you could see if phpsloppypig.org is available (it is btw). Cheers, Rob. -- ... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
Real life is rarely optimal. That's not a valid excuse for taking the sloppy pig route to development. Sloppy pig's give conscientious developers a bad name. And when they use PHP to create their slop, they give PHP a bad name. Well I err towards actually doing something useful. Businesses can rarely wait while developers create a technically perfect application. Those that do are rarely successful. As always there's a balance to be struck between writing technically perfect code and getting the job done. You would think you would lean towards conscientiousness since you use an email address with phpguru in it. But I guess anyone can claim whatever they want... it doesn't make it true. Maybe you could see if phpsloppypig.org is available (it is btw). Ah personal insults. Always a good argument. -- Richard Heyes http://www.websupportsolutions.co.uk Knowledge Base and HelpDesk software that can cut the cost of online support ** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON-PROFITS ** -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
Richard Heyes wrote: Real life is rarely optimal. That's not a valid excuse for taking the sloppy pig route to development. Sloppy pig's give conscientious developers a bad name. And when they use PHP to create their slop, they give PHP a bad name. Well I err towards actually doing something useful. Businesses can rarely wait while developers create a technically perfect application. Those that do are rarely successful. As always there's a balance to be struck between writing technically perfect code and getting the job done. I don't see a reason to compromise. It would take no longer to call extension_loaded on each page request than it will to put the variable in the session. You're right in saying that there's a balance to be struck, but in this particular case I personally see a right way and a wrong way and no compromise needed to do it properly. You would think you would lean towards conscientiousness since you use an email address with phpguru in it. But I guess anyone can claim whatever they want... it doesn't make it true. Maybe you could see if phpsloppypig.org is available (it is btw). Ah personal insults. Always a good argument. I couldn't care less what your domain name is, you're still advocating a poor choice IMHO. -Stut -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
I don't see a reason to compromise. It would take no longer to call extension_loaded on each page request than it will to put the variable in the session. You're right in saying that there's a balance to be struck, but in this particular case I personally see a right way and a wrong way and no compromise needed to do it properly. I think the discussion has moved beyond extension_loaded(), but in that case, yes, personally I would use extension_loaded() directly. Probably in a factory type function which returns the appropriate type of object. I couldn't care less what your domain name is, you're still advocating a poor choice IMHO. Practical though. And I'm conscientious as far as business allows. -- Richard Heyes http://www.websupportsolutions.co.uk Knowledge Base and HelpDesk software that can cut the cost of online support ** NOW OFFERING FREE ACCOUNTS TO CHARITIES AND NON-PROFITS ** -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
Stut wrote: I couldn't care less what your domain name is, you're still advocating a poor choice IMHO. I have been trying hard not to join this thread, but ... apart from the principle, what's _really_ so poor about it? Having to write application code that needs to work with two different APIs is poor enough, using a session variable for keeping a status won't make it much worse. So what if the status is server-scope, yet kept in user-scope. In particular if the app already uses session storage. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
On Tue, 2007-12-11 at 17:01 +, Richard Heyes wrote: Real life is rarely optimal. That's not a valid excuse for taking the sloppy pig route to development. Sloppy pig's give conscientious developers a bad name. And when they use PHP to create their slop, they give PHP a bad name. Well I err towards actually doing something useful. Businesses can rarely wait while developers create a technically perfect application. Those that do are rarely successful. As always there's a balance to be struck between writing technically perfect code and getting the job done. You would think you would lean towards conscientiousness since you use an email address with phpguru in it. But I guess anyone can claim whatever they want... it doesn't make it true. Maybe you could see if phpsloppypig.org is available (it is btw). Ah personal insults. Always a good argument. It was just a suggestion... if you take it as an insult perhaps it hit a chord. Cheers, Rob. -- ... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
On Tue, 2007-12-11 at 18:14 +0100, Per Jessen wrote:
Stut wrote:
I couldn't care less what your domain name is, you're still advocating
a poor choice IMHO.
I have been trying hard not to join this thread, but ... apart from the
principle, what's _really_ so poor about it? Having to write
application code that needs to work with two different APIs is poor
enough, using a session variable for keeping a status won't make it
much worse. So what if the status is server-scope, yet kept in
user-scope. In particular if the app already uses session storage.
It's bad because it places data in a storage area not related to the
kind of configuration being tracked. Sessions are for managing user and
user related data. This particular value is related to the server in
general. It places a large WTF factor on the code for anyone down the
road maintaining it. It may be true that nobody else will ever manage
this code, but it's unlikely. I absolutely agree with you though, the
whole design is off. The best way to do this IMHO is to use a singleton
class that only loads the appropriate library type. Then the interface
would be generic and no extension switching would occur once the library
is loaded. Functional equivalents can be used to facilitate the same
design pattern as the singleton... such as a stub library containing one
function:
File: db.stub.php
?
function getConnection( $dbConnectionParams )
{
if( extension_loaded( 'mysqli' ) )
{
require_once( 'db.layer.mysql.php' );
}
else
if( extension_loaded( 'mysql' ) )
{
require_once( 'db.layer.mysqli.php' );
}
else
{
die( 'No appropriate database library installed' );
}
}
?
Then only the necessary code would be loaded and all db function (or
method) requests would execute only the appropriate code without
run-time switching. This is not only fairly optimal, but simpler,
cleaner, and much more maintainable.
Cheers,
Rob.
--
...
SwarmBuy.com - http://www.swarmbuy.com
Leveraging the buying power of the masses!
...
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
On Tue, 2007-12-11 at 22:11 +0100, Per Jessen wrote: Robert Cummings wrote: On Tue, 2007-12-11 at 18:14 +0100, Per Jessen wrote: I have been trying hard not to join this thread, but ... apart from the principle, what's _really_ so poor about it? Having to write application code that needs to work with two different APIs is poor enough, using a session variable for keeping a status won't make it much worse. So what if the status is server-scope, yet kept in user-scope. In particular if the app already uses session storage. It's bad because it places data in a storage area not related to the kind of configuration being tracked. Sessions are for managing user and user related data. This particular value is related to the server in general. It places a large WTF factor on the code for anyone down the road maintaining it. Possibly, but nothing that a single line comment won't explain. Making a potentially poor decision is bad, but explaining why takes most of the sting out of it. It may be true that nobody else will ever manage this code, but it's unlikely. I absolutely agree with you though, the whole design is off. The best way to do this IMHO is to use a singleton class that only loads the appropriate library type. I can't remember what sort of environment the OP was in, but if any sort of organised testing is done, the use of two different APIs will just about double the test-effort. Which is why I still think the best option is to mandate _one_ of the APIs and choose your hoster accordingly. Well if you write unit tests, having the unit tests applied to one or the other is the same amount of work since it just requires a switch to change between mysql and mysqli. Cheers, Rob. -- ... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
On Dec 11, 2007 4:11 PM, Per Jessen [EMAIL PROTECTED] wrote: I can't remember what sort of environment the OP was in, but if any sort of organised testing is done, the use of two different APIs will just about double the test-effort. Which is why I still think the best option is to mandate _one_ of the APIs and choose your hoster accordingly. ideally there should be an abstraction layer. beneath it either mysql or mysqli would work. this is the nature of any respectable database layer. it prevents a need to modify stable client code (written against the abstraction layer) when you have to switch the underlying database client. -nathan
Re: [PHP] Mysqli support - test or complain? [SOLVED]
Robert Cummings wrote: On Tue, 2007-12-11 at 18:14 +0100, Per Jessen wrote: I have been trying hard not to join this thread, but ... apart from the principle, what's _really_ so poor about it? Having to write application code that needs to work with two different APIs is poor enough, using a session variable for keeping a status won't make it much worse. So what if the status is server-scope, yet kept in user-scope. In particular if the app already uses session storage. It's bad because it places data in a storage area not related to the kind of configuration being tracked. Sessions are for managing user and user related data. This particular value is related to the server in general. It places a large WTF factor on the code for anyone down the road maintaining it. Possibly, but nothing that a single line comment won't explain. Making a potentially poor decision is bad, but explaining why takes most of the sting out of it. It may be true that nobody else will ever manage this code, but it's unlikely. I absolutely agree with you though, the whole design is off. The best way to do this IMHO is to use a singleton class that only loads the appropriate library type. I can't remember what sort of environment the OP was in, but if any sort of organised testing is done, the use of two different APIs will just about double the test-effort. Which is why I still think the best option is to mandate _one_ of the APIs and choose your hoster accordingly. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
On Tuesday 11 December 2007, Per Jessen wrote: Stut wrote: I couldn't care less what your domain name is, you're still advocating a poor choice IMHO. I have been trying hard not to join this thread, but ... apart from the principle, what's _really_ so poor about it? Having to write application code that needs to work with two different APIs is poor enough, using a session variable for keeping a status won't make it much worse. So what if the status is server-scope, yet kept in user-scope. In particular if the app already uses session storage. Are you saying there's something wrong with doing something non-stupid on principle? Any employer that wants me to cut even small corners like that to do something sloppy to save the 10 seconds it would take to do it right can find a new programmer, thank you. (The market is good enough that you can say that, if you're good enough.) You could also make every property of an object public, or always use an input/output parameter to a function instead of a return. They would all work. That doesn't mean any of those aren't dumb. For all those suggesting that adding an if() check is better than caching it to the session, you're right. It's also still less than optimal. You have a database config file somewhere that stores your database credentials. Put which DB driver to use in there. It's not like it's going to change, and you have to edit that file anyway to install the app. It's part of the database configuration. Most of the open source systems I've seen do that in some form or another. And if you don't know what driver you have on your system, it's not like it's hard to try one, watch it die, and then use the other. :-) How did this get so complicated? -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it. -- Thomas Jefferson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
Zoltan, Per, Richard, Chris, Daniel, Larry, Thank you for responding. I have created a method in the class that handles my database connections that will first test on extension_loaded(mysqli) before connecting to the database. Then I store the result in a session variable for reference, so future calls will use the correct mysqli or regular syntax. Thank you for helping me to find this solution. My scripts are that much more portable now. -- Dave M G -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain? [SOLVED]
On Tue, 2007-12-11 at 13:02 +0900, Dave M G wrote: Zoltan, Per, Richard, Chris, Daniel, Larry, Thank you for responding. I have created a method in the class that handles my database connections that will first test on extension_loaded(mysqli) before connecting to the database. Then I store the result in a session variable for reference, so future calls will use the correct mysqli or regular syntax. Thank you for helping me to find this solution. My scripts are that much more portable now. You use a session variable for that? That's entirely the wrong place to store something like which database API is installed. It should a class variable or global configuration variable. Heck, I'd say it's more appropriate to do extension_loaded( 'mysqli' ) on every call than to use a session variable. Cheers, Rob. -- ... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
