mysqli db port support

[thornag]

Hi there,

Just grabbed the latest 2.1.2 version with all the php5 improvements that I really appreciate.

Run into a problem when installing using the MySQL5 driver and mysqli

The mysqli constructor

Code: Select all

mysqli::__construct ([ string $host = ini_get("mysqli.default_host") [, string $username = ini_get("mysqli.default_user") [, string $passwd = ini_get("mysqli.default_pw") [, string $dbname = "" [, int $port = ini_get("mysqli.default_port") [, string $socket = ini_get("mysqli.default_socket") ]]]]]] )

expects the port number to be the 5th parameter and unlike PDO it won't read it off the hostname string.

So if you are not running DB on default port you won't be able to connect.

Could do with adding the port to the config or just by parsing the hostname better.

edit:

Another thing noticed. When supplied custom names/prefixes for the generated wurfl tables the SPs are still created using the predefined values.

This is visible in 437 TeraWurfl_MySQL5.php in method public function createProcedures(){ where first procedure is created using config but the second procedure is using hardcoded table names

[kamermans]

Hi thornag, thanks for your analysis! I will definitely be integrating the changes you suggested in version 2.1.3. I will parse the given hostname for a port, specified by using ':' as a delimiter - this way I can maintain compatibility with the other database connectors (like MSSQL). Thanks for the tip about the stored procedures using hardcoded table names - I added the table prefix feature a long time ago and rarely test it since it is not frequently used. Please let me know if you find any other issues.

Thank you for your support!

[thornag]

Hi,

Don't want to be a smart-ass here but I got few more thought you may consider.

One of the problems I can see is that the 'capabilities capture' engine is too much connected with the wurfl xml parser and insert DB operations.

This is creating code dependencies that are generally hard to remove in current form.

For example, on production server I don't want admin to be in my source files, as in most cases you will have separate admin servers.

Now the TeraWurfl class used for recognition is requiring TeraWurflLoader which is not needed if I only want to run UA through database.

I think it would be wise to split the classes a little bit more into smarter directory structure

Engine lib - where all the matching stuff happens, this would have all the UAMatchers etc, Utulities etc, this would be always needed for matching and admin
Admin classes, for updates, parsing raw xml, usage test etc
The main class doig matching.
WebService

That way I would not have to deploy files that will never be used to the production server. It's not a biggie but should sure make the application more interesting for businesses and stuff.

edit--

public function getDeviceCapabilitiesFromRequest($server){
if(!isset($server))$server = $_SERVER;
return getDeviceCapabilitiesFromAgent(WurflSupport::getUserAgent($server),WurflSupport::getAcceptHeader($server));
}

this is missing $this

[kamermans]

Don't worry, I don't mind constructive criticism I have had this discussion about file/folder structure with a few other people in the last year as well. They and I agree with you that the code should be separated. I am working on a concept for the next major version which will certainly include this feature. It will be quite a while before it's released; I am working closely with the WURFL guys to make sure it is compatible with the new WURFL (in the concept stage as well).

Thanks for the tip about the missing "$this->" I have made the appropriate change to the source tree: http://github.com/kamermans/Tera-WURFL/commits/master

If you grab a copy of code from GitHub, it has MySQLi port change and many other updates in it: http://github.com/kamermans/Tera-WURFL/