On Wed, Jan 29, 2003 at 11:53:00PM +0100, Garvin Hicking wrote:
Because they will have the latest version...isn't this most usual reason to update?
Hm, as a bleeding-edge user of course. But I know of a lot phpMyAdmin- Installations using 2.2.xxx
Same here, I've had to use a few of the older ones myself on client projects anyway. It really won't hurt to only have your feature in 2.4.1 the way I see it, many sysadmins will avoid 2.4.0 because of the stigmata associated with point releases, and wait for 2.4.1 at the least.
Hope everything goes as smoothly as I worked it on my imagination. :-)
Heh, there are always some bumps along the way, the SQL parser I wrote last summer is twice the size I predicted it would be, mostly because of all the odd little corner cases that had to get covered.
I think for the first step column transformations will not work for aliases columns. Like when I define a 'image/jpeg'-Transformation on the field 'image' I will see the transformation with a query like 'SELECT image FROM table' but will not see it if I use 'SELECT image AS bild FROM table'. That means, the column name has to match a comment entry. Using 'SELECT image_new AS image' instead will transform the image using the 'image/jpeg'-Transformation.
Our SQL query analyzer system can tell you what columns are aliased and much much more, so this shouldn't be a problem.
I think the column name should not be used to define what type of transform is used, as that restricts the user a lot. Instead just base the transform off the specified mimetype.
Oh, and once you write up the code for putting the mime-type in, I'll contribute a little bit of code that can auto-detect what mime-type a data field should be if there is data in the field but no mime-type specified. It's just a little bit of code I have kicking around my personal archives that I wouldn't mind putting to better use.