[Devel] Problem with table_version in db.c

[Matty]

On Sun, 2 Jul 2006, Daniel-Constantin Mierla wrote:

> Hello,
>
> On 07/02/06 20:07, Matty wrote:
>> 
>> Howdy,
>> 
>> When I attempt to start openser, I am greeted with the following error 
>> (please continue reading for the reason why):
>> 
>> $ openser
>> 
>> [ ..... ]
>>  0(0) usrloc:preload_udomain: Wrong version v2134024 for table <location>, 
>> expected v1001
>>  0(0) register_udomain(): Error while preloading domain 'location'
>>  0(0) pool_remove: Removing connection from the pool
>>  0(0) domain_fixup(): Error while registering domain
>> 
>> I checked the MySQL database (5.22) table and the query being issued, and 
>> they both check out:
>> 
>> $ mysql -uroot -p -hmysql
>> Enter password:
>> Welcome to the MySQL monitor.  Commands end with ; or \g.
>> Your MySQL connection id is 35 to server version: 5.0.22-log
>> 
>> Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
>> 
>> mysql> use openser
>> Reading table information for completion of table and column names
>> You can turn off this feature to get a quicker startup with -A
>> 
>> Database changed
>> mysql>  select table_version from version where table_name='location';
>> +---------------+
>> | table_version |
>> +---------------+
>> |          1001 |
>> +---------------+
>> 1 row in set (0.00 sec)
>> 
>> To see what was going on, I added a break point to table_version and dumped 
>> res.rows.values just prior to the function returning:
>> 
>> (gdb) p *res.rows.values
>> $7 = {type = DB_STRING, nul = 0, val = {int_val = 2134056,
>>       double_val = 4.6067679823539676e-308, time_val = 2134056,
>>       string_val = 0x209028 "1001", str_val = {s = 0x209028 "1001",
>>       len = 0}, blob_val = {s = 0x209028 "1001", len = 0},
>>       bitmap_val = 2134056}}
>> 
>> Upon inspecting the code in table_version, I noticed that the VAL_INT MACRO 
>> is used to return val.int_val to the calling function:
>> 
>> /* From db.c */
>> ret = VAL_INT(ROW_VALUES(RES_ROWS(res)));
>> dbf->free_result(connection, res);
>> return ret;
>> 
>> When I dump val.int_val with gdb, I get differenet results each time the 
>> program runs:
>> 
>> (gdb) p *res.rows.values.val.int_val
>> $10 = 825241649
>> 
>> I did a bit more digging, and it looks like the 'type' field is set to 2 
>> (DB_STRING) after the query completes, and val.str_val.s contains the 
>> result:
>> 
>> (gdb) x/s res.rows.values.val.str_val.s
>> 0x209028:        "1001"
>> 
>> With that said, is there a reason that the "type" field isn't checked on 
>> return from the query, and the appropriate result used? I can submit the 
>> patches I am using to address this problem, but I wanted to check with the 
>> development folks to see why the VAL_INT macro is always used.
> VAL_INT is used because the table_version should be integer number, but seems 
> not to be in your case. Please check the structure of table 'version'.
>
> describe version;
> show create table version;
>
> However, the check of the result type should be done as you suggested, I will 
> commit it soon.

Hi Daniel,

I used openser_mysql.sh to create the database. Here is the table 
description and the SQL used to create the version table:

mysql> describe version;
+---------------+-------------+------+-----+---------+-------+
| Field         | Type        | Null | Key | Default | Extra |
+---------------+-------------+------+-----+---------+-------+
| table_name    | varchar(64) | NO   | PRI | NULL    |       |
| table_version | smallint(5) | NO   |     | 0       |       |
+---------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

mysql> show create table version;
+---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table   | Create Table 
|
+---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| version | CREATE TABLE `version` (
   `table_name` varchar(64) NOT NULL,
   `table_version` smallint(5) NOT NULL default '0',
   PRIMARY KEY  (`table_name`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 |
+---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

This seems to match what is the 'create table' statement in 
openser_mysql.sh:

CREATE TABLE version (
    table_name varchar(64) NOT NULL primary key,
    table_version smallint(5) DEFAULT '0' NOT NULL
) $TABLE_TYPE;

I am using openser on a Solaris 10 server, and can provide additional 
details if you need them.

- Ryan
--
UNIX Administrator
http://daemons.net/~matty