Below is a copy of a message which I sent to the author of "Reminder 2" covering why his module stops working when the db class is set to "mysql4" (but works fine with the "MySQL" class).
Quote:
Hi,
I have mySQL 4 installed on my system, along with the PHP-Nuke db set to "mysql4."
Under this configuration the Reminder 2 module stops functioning correctly (doesn't have reference to the configuration data stored in the database). I've isolated the problem and it is specificly related to the PHP-Nuke db class mysql4.php, and in the "sql_fetchrow" function.
Appearently, the implementation of "sql_fetchrow" is set to create a "MYSQL_ASSOC" array, where the array elements are solely obtained by using the field's symbolic names (Reminder 2 uses numerical references of the fields position in the results).
This method fails because a "MYSQL_ASSOC" fetch only composes an array containing associative array references (i.e., their symbolic field names).
Where as, the MySQL class uses a "mysql_fetch_array" which returns a combination of numerical and associative array elements (thus allowing either type of array element extraction to be applied).
I don't see this as "your problem" per say, since the PHP-Nuke folks have not produced a mysql4 class which duplicates all of the characteristics of the MySQL class. But since some may contact you regarding this problem I thought that you should be aware of it.
_________________ The hippocampus is NOT a place of higher learning for hippopotamuses.
Xyberian Colonel
Joined: Mar 14, 2004
Posts: 1939
Location: Behind you
Posted:
Tue Sep 13, 2005 5:39 pm
Your post is one of my critics on nuke coders. I don't still understand why they are using mysql-dependent codes such as my_sql connect, fect_row assoc etc. Nuke DB codes are all OOP (object oriented programing) classes. This implies that all class objects encapsulate DB connection and provide coders with universal access DBs regardless of whatever popular kinds of DB engine are used. For instance, if your DB engines are MSSQL and Postgress7, then such mysql dependent loosely coded modules will never work on them.
Recently, those modules are probably, reminer, nuke treasury, nuke c30 etc. Well, their codes are under GPL/ GNU/ licenses so that nukers must not complain their efforts. Some of nukers may say like that "at this moment, my phpnuke site work, so I don't need such headach thingies.." This will make you guys be regretful when you move to another system environment and hosting companies. Tiny care will save you and your phpnuke sites safe and much more protable. I hope they realize more OOP styles DB which ignore any types of DB access codes.
Besides the above complaints, for your post, you have to change some codes to make it run in your phpnuke.
I understand your points and I agree with you. After researching this issue a bit more, I discovered that several things are not working on this new installation of PHP-Nuke with the database set to mysql4.
I think that blame for it falls on two things: poor coding practises of those writing third party modules, and relying on someone else's GPL code (in this case, PHP-Nuke's inheriting the db modules from phpBB).
The poor coding practises are when programmers read their field data by numerical reference. For example, if the fields:
"ID", "first_name", "last_name"
are read into an array and referenced in the array numerically, it assumes that there will never be a future situation in which a new field is inserted. Just add:
"ID", "salutation", "first_name", "last_name"
and the code breaks since the field positions changed in the resulting array fetch (i.e., [1] is no longer the "first name", it is the "salutation" field, and so on).
This is completely avoided when using an associative array since the field references are symbolic.
The problem on the PHP-Nuke team's side are that they have elected to use phpBB's database classes. On the plus side they didn't need to write their own. On the down side, they inherit any problems contained within it. In this case, it is an inconsistence between the "MySQL" and "mysql4" classes. This "problem" has never surfaced with the phpBB crowd because they are not in the habit of using numerical array references to fetched fields (so the problem is invisible to them. But they also do not have the massive number of third party module support that PHP-Nuke has. So the differences between the two database classes tend not to surface.
What I am utterly amazed at is that this problem hasn't surfaced before.
Incidentially, for you PHP-Nuke developers, the fix to this problem is to edit mysql4.php and replace each instance of "MYSQL_ASSOC" with "MYSQL_BOTH".
The original mysql.php never included the array type to be returned, so it defaulted to "MYSQL_BOTH". But whoever wrote phpBB's mysql4.php class included "MYSQL_ASSOC" in the data return type field.
Personally, I think that PHP-Nuke should look into the possibility of using the ADOdb Database Abstraction Library for PHP (see: http://adodb.sourceforge.net/). It is incredibly fast, supports a high speed interface which makes it even faster on busy installations (see: ADOdb extension), and provides an interface to over 38 database systems (see: http://phplens.com/lens/adodb/docs-adodb.htm#drivers).
Of course, changing db interface directions is an issue since so many people have coded to the phpBB standard. So there would be a further need to create an additional level of abstraction to support legacy code (i.e., create a layer to cross reference the phpBB commands to the ADOdb interface).
Anyway, I'll bet anyone a cup of coffee that this issue doesn't get fixed or make its way into future versions of PHP-Nuke until more peiople are using mySQL4. In fact, I'll bet that a bunch of folks have already encountered it and switched their settings back to "MySQL" because most of the problems disappeared (giving them less reason to report the bug).
Cheers,
Tim
_________________ The hippocampus is NOT a place of higher learning for hippopotamuses.
Xyberian Colonel
Joined: Mar 14, 2004
Posts: 1939
Location: Behind you
Posted:
Wed Sep 14, 2005 12:46 am
Try to "mysql" instead of "mysql4" in config.php file. I strongly recommend nukers to use "mysql" not "mysql4." As you saw into DB core files to establish OOP styles classes, mysql specification is better. After then you may use general query statements such as fetchrow & numrows with out assocication and _both options.
Your post is one of my critics on nuke coders. I don't still understand why they are using mysql-dependent codes such as my_sql connect, fect_row assoc etc. Nuke DB codes are all OOP (object oriented programing) classes. This implies that all class objects encapsulate DB connection and provide coders with universal access DBs regardless of whatever popular kinds of DB engine are used. For instance, if your DB engines are MSSQL and Postgress7, then such mysql dependent loosely coded modules will never work on them.
Recently, those modules are probably, reminer, nuke treasury, nuke c30 etc. Well, their codes are under GPL/ GNU/ licenses so that nukers must not complain their efforts. Some of nukers may say like that "at this moment, my phpnuke site work, so I don't need such headach thingies.." This will make you guys be regretful when you move to another system environment and hosting companies. Tiny care will save you and your phpnuke sites safe and much more protable. I hope they realize more OOP styles DB which ignore any types of DB access codes.
Besides the above complaints, for your post, you have to change some codes to make it run in your phpnuke.
Woow Xyberian,
where did you get those stupid thoughts about "reminder, nuke treasury, nuke c30".
Did you ever looked closelly at them or it's just another "probablly" thing to you.
"Probablly" not but. You just talk without knowing nothing about them, isn't it.
Before saying these kind of words about others add-ons, modules or [generally] anything else you should know something about it. Don't you?
Otherwise don't "probablly" around here and say lies.
I wrote Reminder and can tell you for sure that I didn't used direct php mysql function to make queries from db.
Why should I use those functions when I have a more simple and conveniant way [through bd class].
You are living in ice age?
Nobody uses directlly these functions nowadays [ when making new modules for php-nuke]. "Probablly" you just read somewhere about these old habbits and spit it out here.
Ishtaria said that is a problem with php-nuke when using mysql4 and making queries like:
$result = $db->sql_query("SELECT * FROM ".$blabla."_blabla");
$row = $db->sql_fetchrow($result);
$variable = $row['5'];
[good or bad practice is corectlly and works perfectlly in mysql]
Instead we should use[it's also more intuitive]:
$result = $db->sql_query("SELECT * FROM ".$blabla."_blabla");
$row = $db->sql_fetchrow($result);
$variable = $row['field_name'];
Again this is an issue only for mysql4 users [but also is a good point].
And he also came with a simple and effective solution for mysql4 users.
But from this and saying that "probablly" Reminder [without even looking at this module] uses the old syntax to query the db I don't see any connection.
I see you have a lot of post here on nukecops but you don't know how to behave in a community.
Hope you learned a simple and common sense lesson today: Don't talk or write about things you don't have a clue.
Don't bother to apologize.
Everybody who will see this thread will draw the right conclusion about you. It's enough for me.
Ishtaria Nuke Soldier
Joined: Apr 22, 2003
Posts: 22
Posted:
Wed Oct 05, 2005 1:10 am
Xyberian wrote:
Try to "mysql" instead of "mysql4" in config.php file. I strongly recommend nukers to use "mysql" not "mysql4." As you saw into DB core files to establish OOP styles classes, mysql specification is better. After then you may use general query statements such as fetchrow & numrows with out assocication and _both options.
My "mysql.php" and "mysql4.php" are not "specifications." They are each implemented around a specific version of the mySQL database.
_________________ The hippocampus is NOT a place of higher learning for hippopotamuses.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
