[Phpmyadmin-devel] 2.3.0 schedule

[Robin Johnson]

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.

-- 
Robin Hugh Johnson
E-Mail     : robbat2 at orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639