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]
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]
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 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]
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]
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]
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 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 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 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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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
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?
On Monday 10 December 2007, Dave M G wrote: > One is based on the assumption that mysqli is as likely not to be > available as it is to be installed. In this case I should write my > scripts to test whether it exists and then use either mysqli or straight > mysql commands as appropriate. If this is the way to go, what do I do to > test for the existence of mysqli from within a PHP script? > > The other is to assume that recent installs and upgrades of PHP > 5 > should have mysqli because that's the currently preferred way of doing > things, and therefore I should contact the web host and ask that they > install it, or I find a different host. > > Which assumption should I be proceeding with? > > Thank you for any advice or assistance. > > -- > Dave M G ext/mysqli is not part of the stock install of any version of PHP. Some shared hosts install it, some do not. PDO, as of PHP 5.1, is part of the stock install. Nearly any shared host that has MySQL will install the PDO-MySQL backend driver. I'd say this is the most likely MySQL connection method you'll find on a modern host. (A host that doesn't offer PHP 5.2 or later by default is not one you want to do business with. http://gophp5.org/ ) ext/mysql used to be part of the stock install of PHP, but has not been since PHP 5.0 for assorted legal reasons. Most shared hosts install it anyway for legacy support, but you shouldn't use it because it hasn't had any worthwhile updates since MySQL 3 or so. Securing queries in PDO or mysqli is far far far easier. My recommendation is to use PDO rather than mysqli if you don't control the server configuration. If you can be choosy about the host, then write what you want and only pick hosts that will support you. Even better, if you are able to do so, write your own thin abstraction layer that uses PDO or mysqli internally. Then you can switch from one to the other more easily if you find you need to, and you can also add whatever syntactic convenience sugar you want. -- 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?
Per Jessen wrote: Richard Heyes wrote: another. This is one of the reasons abstraction layers exist. Which brings us to alternative #3 - odbc. That's probably less likely to be available than mysqli. If you're targetting php5 then you could use pdo::mysql as well (and there's even the less available dbx functions). Good thing about php = so many options Bad thing about php = too many options :) -- Postgresql & php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain?
On Dec 10, 2007 3:16 AM, Dave M G <[EMAIL PROTECTED]> wrote:
> Which assumption should I be proceeding with?
Rather than assume (because we all know what happens then), why
not build for both scenarios? Here's an example of one way
'.mysql_error()."\n");
} else {
$db_conn = mysql_connect($_DB[host],$_DB[user],$_DB[pass]) or die
('I couldn\'t connect to the database. Know why? Because MySQL is
complaining about something. Does this make sense to you...? :'.mysql_error()."\n");
}
?>
\n";
$err .= "";
if(function_exists('mysqli_error')) {
$err .= mysqli_error();
} else {
$err .= mysql_error();
}
$err .= "\n";
$err .= "\n";
return $err;
}
function db_query($sql) { // Simply return the connection resource ID
require('inc/config.php');
require('inc/db.php');
// Select the site database
if(function_exists('mysqli_query')) {
$db_select = mysqli_select_db($_DB[name],$db_conn);
} else {
$db_select = mysql_select_db($_DB[name],$db_conn);
}
return $r;
}
?>
--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]
If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain?
Richard Heyes wrote: > another. This is one of the reasons abstraction layers exist. Which brings us to alternative #3 - odbc. /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?
How exactly do I test for the presence of mysqli from within a script? IIRC there's a function called extension_loaded(). Or something similar. Or are you saying I have two different versions of my script? Not at all. Taking PEAR::DB for example, you could test for the existence of mysqli, and use one DSN if it's there. If not, use another. This is one of the reasons abstraction layers exist. -- 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?
Dave M G wrote: > Richard said: > > Alter your program to support both - use mysqi if it's avilable, >> mysql if it's not. > > How exactly do I test for the presence of mysqli from within a script? > Or are you saying I have two different versions of my script? I think you can test for the availability of an extension, but I don't know how. I'm sure someone will be able to tell us. To enable your script to use one or the other, you could wrap each database call in your own "mysqldave()", which would check the mysqli availability and call the appropriate API. You'd obviously check the mysqli availability at startup, then store the status somewhere for your wrapper to query. /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?
2007. 12. 10, hétfő keltezéssel 21.58-kor Dave M G ezt írta:
> Richard, Per, Andres,
>
> Thank you for responding.
>
> If it were entirely my web site to dictate what to do with, I would just
> switch for a server that has mysqli available to me.
>
> However, in this one case, the web site is owned by a small, not very
> profitable group that has reasons to stay with their current webhosting
> service. I want to support them if possible.
>
> Richard said:
> > Alter your program to support both - use mysqi if it's avilable,
> > mysql if it's not.
>
> How exactly do I test for the presence of mysqli from within a script?
for example
if (function_exists('mysqli_connect'))
greets
Zoltán Németh
>
> Or are you saying I have two different versions of my script?
>
> --
> 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?
Richard, Per, Andres, Thank you for responding. If it were entirely my web site to dictate what to do with, I would just switch for a server that has mysqli available to me. However, in this one case, the web site is owned by a small, not very profitable group that has reasons to stay with their current webhosting service. I want to support them if possible. Richard said: > Alter your program to support both - use mysqi if it's avilable, mysql if it's not. How exactly do I test for the presence of mysqli from within a script? Or are you saying I have two different versions of my script? -- 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?
> -Original Message- > From: Per Jessen [mailto:[EMAIL PROTECTED] > > Dave M G wrote: > > > One is based on the assumption that mysqli is as likely not to be > > available as it is to be installed. In this case I should write my > > scripts to test whether it exists and then use either mysqli or > > straight mysql commands as appropriate. If this is the way to go, > what > > do I do to test for the existence of mysqli from within a PHP script? > > In my opinion, that is overkill. If you need mysqli and a provider > does > not provide it, simply chose another provider. A lot less effort. > > > The other is to assume that recent installs and upgrades of PHP > 5 > > should have mysqli because that's the currently preferred way of > doing > > things, and therefore I should contact the web host and ask that they > > install it, or I find a different host. > > > > Which assumption should I be proceeding with? > > Find a provider/hoster that meets your requirements. You're the > customer. > > > /Per Jessen, Zürich > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php Yes but what about development clients that have their hosting accounts elsewhere?... you cannot push them to change from hosting provider. I would rephrase Dave's questions like this: 1 - What is the chance your clients have PHP 5 nowadays? 2 - What is the change that a PHP 5 hosting provider has mysqli installed? Multiply both and you get the chance of getting mysqli installed when a new development client arrives asking for a development quote... If you are a company, you can provide the PHP 5 hosting yourself, and have a "PHP 5 Required" rule in the TOS for development projects. But if you are a freelancer... you risk loosing the client with such a requirement. Despite the EOL for PHP 4 has been announced, I still see webhosts bundled with PHP 4.1 and MySQL 3.23. Anyway... it depends on your target, and the real need for mysqli. Rob Andrés Robinet | Lead Developer | BESTPLACE CORPORATION 5100 Bayview Drive 206, Royal Lauderdale Landings, Fort Lauderdale, FL 33308 | TEL 954-607-4207 | FAX 954-337-2695 Email: [EMAIL PROTECTED] | MSN Chat: [EMAIL PROTECTED] | SKYPE: bestplace | Web: http://www.bestplace.biz | Web: http://www.seo-diy.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Mysqli support - test or complain?
One is based on the assumption that mysqli is as likely not to be available as it is to be installed. In this case I should write my scripts to test whether it exists and then use either mysqli or straight mysql commands as appropriate. If this is the way to go, what do I do to test for the existence of mysqli from within a PHP script? The other is to assume that recent installs and upgrades of PHP > 5 should have mysqli because that's the currently preferred way of doing things, and therefore I should contact the web host and ask that they install it, or I find a different host. Which assumption should I be proceeding with? You can: 1. Change your program to use the much more common mysql extension and forget about mnysqli for the time being (this is what I would do). You can switch to mysqli when its use becomes prevalent. 2. State that mysqli is required and not change anything (not advisable) 3. Alter your program to support both - use mysqi if it's avilable, mysql if it's not. If you use an API and not the mysqli functions directly this won't be too much hassle. Your last option to to assume that it's installed is very bad indeed. You shouldn't ever make assumptions, particularly when your dealing with software distributions. -- 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?
Dave M G wrote: > One is based on the assumption that mysqli is as likely not to be > available as it is to be installed. In this case I should write my > scripts to test whether it exists and then use either mysqli or > straight mysql commands as appropriate. If this is the way to go, what > do I do to test for the existence of mysqli from within a PHP script? In my opinion, that is overkill. If you need mysqli and a provider does not provide it, simply chose another provider. A lot less effort. > The other is to assume that recent installs and upgrades of PHP > 5 > should have mysqli because that's the currently preferred way of doing > things, and therefore I should contact the web host and ask that they > install it, or I find a different host. > > Which assumption should I be proceeding with? Find a provider/hoster that meets your requirements. You're the customer. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Mysqli support - test or complain?
PHP List, Based on what seemed to be good advice to switch to using mysqli for interacting with a MySQL database, I built a content management system that uses mysqli for all it's calls. It works great on a lot of my servers. However, I just discovered that one web hosting service I use does not have mysqli enabled. I ran the phpinfo() command and they are running 5.2.5, but the configure command does not contain "--with-mysqli". I would like the scripts I've written to be somewhat portable, but I'm unsure of whether or not I should assume that mysqli is in use. I see it as being a situation of essentially two options. One is based on the assumption that mysqli is as likely not to be available as it is to be installed. In this case I should write my scripts to test whether it exists and then use either mysqli or straight mysql commands as appropriate. If this is the way to go, what do I do to test for the existence of mysqli from within a PHP script? The other is to assume that recent installs and upgrades of PHP > 5 should have mysqli because that's the currently preferred way of doing things, and therefore I should contact the web host and ask that they install it, or I find a different host. Which assumption should I be proceeding with? Thank you for any advice or assistance. -- Dave M G -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
