On 9/20/06, Al-Faisal El-Dajani <[EMAIL PROTECTED]> wrote:
Well, about Die, yes queries should be correct in the deployment stage, and usually you won't face database problems in very small applications, but when you go a little bit big, you would find that at sometime the database system crashes, or while someone else is working on the same server he accidantly dropped your database or a table in it (that's why we keep backups), or at some extreme cases, someone might try to do some sql injection at your site (given that you took it into considration) and produced an sql with some error, you should handle it in someway, like for example you could show some under maintenance page, and send something to your email, or send you an sms, so you should not strict the way you handle errors to the object, you should notify your client code instead, and let it handle it.
if you are getting on some big applications, and you are trying to let the transactions handeled by the database, You would start considering Stored procedures, a very simple stored procedure could be something like
CREATE PROCEDURE getUserNews ( IN username CHAR(50) )
BEGIN
This stored procedure works correctly on mysql, but if you called it from mysql_query("CALL getUserNews('$username')"), you would have a mysql error, also this could get further in using prepared statments and other good thing in mysql, the MySQLi extention handles these things and makes your life easier.
Well, it's rare, but it happens, for example you have the users profile on some server, but your application is residing on another server, what about you want the users to login, or modify there profiles through your application, yes it's not that good, but sometimes you need it.
I'm not a fan of Procedural Code, and OO is not just using classes, it's a lot far from that, maybe it's a good start though, but if you want to encapsulate the DB stuff, you should think a lot bigger than this, for example a DB connection class, that opens and closes the connection and does the queries for you, a DB Result class that handles results for you, and so on.
Why do you want to that, well just cosider what you would go through if at some point you wanted to change the database engine to something else ;)
you are welcome
Not annoying at all.. instead you're extra helpful.. for instance i didn't know that 0 == null would return true.
About your points:
1) Absolutely correct. Die was a bad choice. But usually when it reaches deployment stage, your queries should be correct by then. die is more of a help during development.
Well, about Die, yes queries should be correct in the deployment stage, and usually you won't face database problems in very small applications, but when you go a little bit big, you would find that at sometime the database system crashes, or while someone else is working on the same server he accidantly dropped your database or a table in it (that's why we keep backups), or at some extreme cases, someone might try to do some sql injection at your site (given that you took it into considration) and produced an sql with some error, you should handle it in someway, like for example you could show some under maintenance page, and send something to your email, or send you an sms, so you should not strict the way you handle errors to the object, you should notify your client code instead, and let it handle it.
2) Didn't follow you there. Can you rephrase?
if you are getting on some big applications, and you are trying to let the transactions handeled by the database, You would start considering Stored procedures, a very simple stored procedure could be something like
CREATE PROCEDURE getUserNews ( IN username CHAR(50) )
BEGIN
SELECT `Article_ID` FROM `Articles` WHERE `author` = username;
ENDThis stored procedure works correctly on mysql, but if you called it from mysql_query("CALL getUserNews('$username')"), you would have a mysql error, also this could get further in using prepared statments and other good thing in mysql, the MySQLi extention handles these things and makes your life easier.
3) Noted.
4) hmm, i never saw or used phpdoc. I wrote them the way i used to do with javadoc. Didn't think there would be any difference really.
take a look at http://www.phpdoc.org/
5) Noted.
6) That actually never crossed my mind. I never had to connect to more than one database, and that option didn't occur to me.
Well, it's rare, but it happens, for example you have the users profile on some server, but your application is residing on another server, what about you want the users to login, or modify there profiles through your application, yes it's not that good, but sometimes you need it.
7) I wrote the entire file primarily because of my need for db_1row and db_0or1row. I needed some way to detect during development if my queries are returning the correct number of rows. I chose a class, simply because i never wrote OO PHP before, and decided to take a go at it. You think a lib file would be more appropriate in this case?
I'm not a fan of Procedural Code, and OO is not just using classes, it's a lot far from that, maybe it's a good start though, but if you want to encapsulate the DB stuff, you should think a lot bigger than this, for example a DB connection class, that opens and closes the connection and does the queries for you, a DB Result class that handles results for you, and so on.
Why do you want to that, well just cosider what you would go through if at some point you wanted to change the database engine to something else ;)
And thanx for your feedback, extremely valuable. :)
you are welcome
On 9/20/06, Ala'a Ibrahim < [EMAIL PROTECTED] > wrote:ok,
Just taking a look at your class, before testing it, I have some points
1. Use of die:Well usually this is not the action the programmer want, if the connection fails, I'd like to handle it in another way, not to crash my whole application, you can throw an exception instead, it's preferable that you extend your own exception for eas of use.2. Using MySQL Library:
e.g. DBConnectionException extends Exception {}; DBSqlException extends Exception {};
you are using PHP5 !Mysql 5 is up there for a lot of time, we use Stored Procedures, MySQL extention is not that good in handling Stored Procedure, as if you have a stored procedure containing a Select Statement to output data, you would have an error calling it, Although MySQLi is available for it, and you can make use of all the features that it comes with.3. line 123 - Error:return mysq_insert_id(); // it should be return mysql_insert_id();4. PHPDoc Tags Need to be fixed:
e.g. @param $database => @param string $database // you should specify the data-type of the parameter5. testing with null using ==:
@return A mysql result set. => @return resource A mysql result set. // Same as above
some functions like db_1row returns a value but no @return is there.the first thing == doesn't check on type, so "" == null is true also 0 == null is true, so you can use the === operator, but when it comes to null, it's always better to use !isset instead.6. More than a database connection:Well, if I'm connecting to more than one server in one page, your class fails in this area, I guess it's so obvious why7. What Does it do exactly:Well, taking a look at this class, the question I asked my self is what this class actually do, it does not give me an abstraction of MySql Database, it doesn't handle connections, it doesn't keep track of it, it only tracks on a result, so if that what is supposed to do you can make it a static class, or even a library with several functions that you might use.
I know I'm annoying here, but you are the one who asked :POn 9/20/06, Al-Faisal El-Dajani <[EMAIL PROTECTED] > wrote:Hey all,
I just wrote this class for database connectivity. Can somebody plz help in testing? Any ideas or suggestions would be great.
Thanx
PS: Requires PHP 5
--
Al-Faisal El-Dajani
Tel: +962-7-77 799 781
P.O Box: 140056
11814 Amman, Jordan
--
Ala'a A. Ibrahim
http://www.alaa-ibrahim.info/
--
Al-Faisal El-Dajani
Tel: +962-7-77 799 781
P.O Box: 140056
11814 Amman, Jordan
--
Ala'a A. Ibrahim
http://www.alaa-ibrahim.info/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Jordan PHP Users Group" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/JoPHP
http://Jolug.org/
-~----------~----~----~----~------~----~------~--~---
