Incorrect detection for BlackBerry Device

[abbasali]

Hello,

The user agent for my device is BlackBerry8300/4.2.2Profile/MIDP-2.0 Configuration/CLDC-1.1 VendorID/107UP.Link/6.2.3.15.0. When tested on my local development server with MySQL v5.1.49-3 this correctly gives the deviceID blackberry8300_ver1_vid102.

However when I run the same test on my production server with MySQL v5.1.50 the device returned is blackberry8300_ver1. This is incorrect and the capabilities returned for this particular device are all generic.

I think I managed to track down the problem to the stored procedure TeraWurfl_RIS which returns the first found device. The above user agent actually matches both blackberry8300_ver1 and blackberry8300_ver1_vid102 devices and since no specific sort order is given in the query different servers will return the results sorted differently. That is why my local server is returning blackberry8300_ver1_vid102 while production server is returning blackberry8300_ver1.

This is not happening for all devices but BlackBerrys are mostly an issue.

[kamermans]

Indeed, I am familiar with this; in fact, in Tera-WURFL 1.x I sorted the results before choosing one, but in 2.x I thought more about it and decided that sorting was unnecessary since whatever device I returned it would still be a reasonable guess. I will probably sort it again just to make the results more predictable, probably something like ORDER BY actual_device_root DESC, deviceID ASC. Do you have any suggestions?

Also, it seems the underlying problem is that the capabilities should be accurate for blackberry8300_ver1. You mentioned that the capabilities are all "generic" which should not be the case. I'll take a look at that device vs. blackberry8300_ver1_vid102 and see if there is anything unusual going on.

[abbasali]

Well I am not sure if sorting by actual_device_root DESC, deviceID ASC will solve the issue because we will still get blackberry8300_ver1 as the first match. One workaround I could think of is adding a new column sort_order to the Merge table but I guess that won't be the ideal solution. Moreover it will be a laborious task to identify each device and populate their sort order manually.

The term "generic" was a bit misnomer on my part . What I meant was that blackberry8300_ver1 was giving me incorrect capabilities. It was returning is_wireless_device. Few capabilities like os, brand etc.. were altogether missing for that deviceID.

Thanks

[kamermans]

We are discussing this internally since we want all the Official WURFL APIs to return the same match.

Also, I took a look at the specific case of blackberry8300_ver1_vid102 vs. blackberry8300_ver1 and in the current WURFL database, their capabilities are identical. As a matter of convention, we do assign device capabilities at the actual device root level (blackberry8300_ver1), as the sub-uas like blackberry8300_ver1_vid102 serve only to help identify a device and send it to the actual device root definition.

[kamermans]

Actually, it sounds like you may be using the database directly, in which case you are getting only part of the capabilities. You will need to descend to the returned device's fall_back and each of their fall_backs all the way back to the root device "generic", that we you get all the capabilities. On the MySQL5 version there is a procedure that will return all the fall_back devices for a given device, and if you use the MySQL5_NestedSet connector, the API can determine and return the entire fall back tree in a simple, single query

[abbasali]

Well, I am not using database directly but using the TeraWurfl class.

I re-installed the database and latest terawurfl code from scratch and that seems to have solved the issue. Perhaps it might be a corrupt database case earlier. Not sure though.

So for now lets just consider this issue solved. If it ever happens again, will let you know.

Thanks Steve.