On Sat, 6 Jul 2002, Marc Delisle wrote:
I suggest a -rc3 on July the 14th, and 2.3.0 on July the 28th.
IMHO the goal is not to fix all bugs. There are some bugs that would need major modifications of the code (for example Relation and order by), and I can live with them in 2.3.0. It's not time for large modifications of the code.
I think you are wrong there Marc. YMMV but with the the number of people that want to use the relation code, I think it should be fixed.
I haven't done any tracing on those two bugs, but could somebody please tell me if the problem can be solved by my parser being able identify the correct tables and fields used in the query?
With my parser at the moment, the actual parser code I would call ready to go (see about the lone bug at the bottom of the email), but the pretty-printer/formatter still needs work.
I've got the parser optimized up the wazoo on purpose, because what it does is really heavy. Currently on the system (P3 666Mhz) I'm using, it takes ~0.49 seconds to parse a string containing all of the CREATE TABLE queries for the mysql database (created with the DUMP feature in PMA). The same string takes about 7 seconds on my old Cyrix 120mhz at home.
Query 1, a lot more common: SELECT PARCELID , COUNT ( FDATE ) FIRE_COUNT FROM FIRES WHERE FDATE >= TO_DATE ( '01-AUG-1988' , 'DD-MON-YYYY' ) GROUP BY PARCELID HAVING COUNT ( FDATE ) > 1 ORDER BY PARCELID ; Takes 0.02 seconds on the big box, and around 0.28 seconds on my Cyrix.
Query 2, CREATE TABLE: CREATE TABLE `news_db` ( `id` int ( 10 ) unsigned zerofill NOT NULL auto_increment , `staff` int ( 10 ) unsigned zerofill NOT NULL default '0000000000' , `location` int ( 10 ) unsigned zerofill NOT NULL default '0000000000' , `title` varchar ( 255 ) NOT NULL default '' , `timedate` timestamp ( 14 ) NOT NULL , `content` mediumtext , `accesstime` timestamp ( 14 ) NOT NULL , PRIMARY KEY ( `id` ) , UNIQUE KEY `id` ( `id` ) , KEY `author` ( `staff` ) , KEY `location` ( `location` ) , KEY `title` ( `title` ) ) TYPE = MyISAM COMMENT = 'News Database' ; Takes 0.71 seconds on my Cyrix, and 0.06 seconds on the big box.
Unfortunetly, during the development, the server I was using to develop it got a little overloaded with some buggy code in the parser while I was working on it (I created enough load to kick the OOM killer into action with an infinite loop). So I got warned off using it. I've been using another system now, of near identical specs (both of them are VALinux boxes, the one I'm on now has 512Mb RAM tho, up from the 256Mb I had before). The only problem is that the server I'm using now is not publically available, I ssh into it and tunnel remotely to it's HTTP port for my development work. I've put in a request to get the HTTP opened up, but it will be a few days at the least before that happens. So until then I'm the only one that has access to my parser code.
Current restrictions/known bugs in my parser:
According the MySQL design specs The table/column/database/alias names can contain all characters in the current MySQL character set, as well as '$' and '_'. The character set includes numbers and upper and lower case letters.
So these are valid names: foo 3foo fo3o _foo $foo micro$oft
I can handle all of those EXCEPT 3foo My parser takes that as a digit, followed by an identifer. Give me a few hours to think about this one, and I'll have a solution for it.
The character set also includes many characters with ascii values about 127 that I can't even type into pine.