Please direct any comments and bug reports to this thread.

At the current time no features will be added to the MySQLi connectors. They are solely intended to be replacements for the current MySQL connectors that have been depreciated in the latest version of PHP and will be removed in a future version.

Any module written to use the xoops api and not access the database directly should work without issue.

Oh yes, and as always with any bug reports please include:
PHP version
MySQL version
Xoops Version

And also include any modules and their versions for any module related issues.

A couple other notes that were brought up in the comments of the news article for this...

If all of your modules strictly use xoops API code or the original MySQL connector and don't access the database directly then yes, simply copying this file and modifying secure.php is all you should have to do.

Having said that I do suspect modules that don't do this will end up needing to be updated. This is not a bad thing however. If someone updates the modules to strictly use the xoops API code they should work for the foreseeable future. Once updated they will work with ANY database that has a connector written for it as long as the developer isn't dependent on some quirk that only happens with MySQL or some other database.

As I mentioned to Mamba in private I will be doing a code review of the modules included in the "Basic Module Pack" to make sure they will work with this connector. I will be scanning the code looking for database calls that need to be converted over to API calls and then install and test the modules to make sure nothing major comes up with them.

I assume if I identify the modules in the pack and then go to the SVN and grab the latest versions I should be good.

There is an issue with the module admin class. The database check is hard coded into the class and it should not be.

The admin class code should dynamically check the connector against the required version. The required versions should be included from the xoops_version file and then this is checked against the version returned from the database connector.

I assume this was done in this manner because of how the admin class came into being. This needs to be changed for 2.5.7 so it will work properly with any future database connectors as well.

I will look it over and work out a solution within the next 48 hours and post it. This will also apply to 2.6.

Rod, great work! We need to move XOOPS into this decade, and this is one of the stumbling blocks.

I do wonder about the use of $GLOBALS. I looked up the tool from Oracle, and I see why it was added, but we already are tracking our connection in the class already, so it seems redundant and unnecessary.

I get the idea that this tool was aimed at the less structured environments where the connection wasn't necessarily available everywhere it might be needed. Since everything should go through this class, it seems like $this->conn should be sufficient.

You've spent much more time looking at this than I have. Is there some reason I'm missing?

There are a couple things I didn't like about the script that was written but it seemed to work. The only issue that has come up is what I will call a programming assumption more than a bug and it hasn't been a big deal.

The Globals item was one of the things I was looking at and another is that where the original connector just returned a value the result of the conversion script was an if than statement. I was hoping that putting this out like this would allow comment and making it a better connector.

The issue with the Module Admin is related to the version check. If you look at the documentation for the calls used the code placed in the class SHOULD work but in reality doesn't work. It also locks the Module Admin class into MySQL, MySQLi and PDO as the database connectors requiring hard coding to add anything else.

At this point I think we can get rid of the switch statement in the admin class and have it just read the current version from the database connector. The database connector then needs to have a function added that will return the version. This will allow someone to just drop in a new connector and need no changes to the code.

I haven't had time to incorporate the code and test it out yet.

I spent some time on this because It would make things a lot easier for me to create a PDO connector. I will take another look through this connector and see if I can simplify some of the code even further. I also wanted to make it easy to move to 2.6 and in reality it took me about an hour to totally convert it to work under 2.6.

Oh and thanks very much for your comments! I hope some others can check it out and share their thoughts as well.

Rod,

I took a deeper look at this, specifically the 2.5 driver, but the results should be relevant anyway.

Using $this->conn instead of the $GLOBAL variable works fine, just as expected. The use of the global connection variable should probably be eliminated.

There are issues with getFieldName() and getFieldType() as both never leave the first column no matter what is specified in the offset. These also have a lot of fluff from the converter program.

getFiledName is easy to fix:


getFieldType is more complicated, but the statement that is in there now is so complex, it would be difficult to maintain. However there is a much bigger issue for future plans. The actual returns in the mysql connector are not clearly defined, and the mysqli functions in PHP returns numeric rather than string data. PDO, as far as I can tell doesn't support that kind of metadata except in an "experimental" method. There does not seem to be any standardization, making the data very driver dependent.

This method doesn't seem to be actively used in the XOOPS world. I have not been able to find a real world test case, just the test I wrote for testing this connector. We should take a serious look at what value it adds to have this method, and consider eliminating it in 2.6 as it seems to be pointless overhead.

I've got a cleaned up version of your 2.5.6 connector. It removes all the $GLOBAL references, and substitutes a big switch to provide names for all of the documented types. (Not exactly elegant, but it doesn't take an hour to figure out what it does.) I would like to get it to you for review; drop me a private email or suggest some other route.

It would be nice to get some support for prepared statements into 2.6 and PDO would be SO COOL! It would also be great if we could get a non-deprecated connector into 2.5.7.

Thanks for all your work!
-Richard

Good job. Thanks.

All work in xoops site, but i use external code (no module) the command mysql_data_seek....

What should I do to fix it. i use this command for page navigation...
i can't use pagenav class of xoops.

if don't possible to resolve no problem, i rewrite all code...

geekwright:

Thanks for testing this out. I was going to try the same thing but have been distracted the past few days. I was working on a patch to make the ModuleAdmin class work with the version checking properly. I have to check it yet against my MySQLi connector and the PDO connector I am working with.

And I actually have a PDO connector with the same level of functionality as the MySQLi connector... I wanted to get this connector out and available since it would hopefully point out some core bugs before I got the PDO connector finished. I am adding a number of new features to the PDO connector as spelled out in the following thread.
https://xoops.org/modules/newbb/viewtopic.php?start=0&topic_id=75217&order=ASC&status=&mode=0

Once I tie up the MySQLi connector and the needed patches to add to 2.5.7 and 2.6 for the versioning to work properly I will be testing some modules against it and will be working more on the PDO connector.

My expectation is that the MySQLi connector will likely be included with the 2.5 series but we will be trying to move to PDO for the 2.6 series.

Thanks for testing the Field name and Type stuff. I thought I tested them but apparently not. I will have to look a little closer at what my tests are testing.
Please check your PM for my email, would love to follow up in email so this can be finished up and ready to be included with 2.5.7 hopefully. And certainly with 2.6.


roby73:
With MySQLi you should be able to use the MySQLi version of the same command. I assume you are making use of the standard MySQL connector and just added some functions not included? If so there are MySQLi versions of most if not all MySQL functions. I can probably help you with this if you have problems. My experience is that some of the commands don't work 100% the same and you may need to adjust them a little but should work.

Be aware that 2.6 will hopefully be moving to fully integrated PDO which may require some additional work. However if you let me know what you are lacking I may be able to roll them into the PDO connector I am building.

This one is significant.

PHP Fatal error: Class 'XoopsMySQLDatabaseProxy' not found in .../xoops_lib/modules/protector/class/ProtectorMysqlDatabase.class.php on line 12

Looks like there is some additional work there to cope with a different connector.