[wp-hackers] RFC on a ticket on trac

[Justas Butkus]

Our implementation, so far, is aimed towards DDL only.
To be more precise - on 'CREATE TABLE' statements parsing. With all 
these flavours, that may occur - we made attempts to handle edge cases 
we do not use so far, but may be obliged to use at some time.

The BackPress approach seems viable. Although our approach is a bit 
different - in that it attempts to parse multitude of SQL variants, 
although compile to as basic SQL as possible, that would be recognized 
by dbDelta. There seems some drawbacks to it, so would we come to get a 
full-fledged replacement for dbDelta - I think it would be reasonable to 
raise more discussion, as to make a solution, that could make into core.

As I see - from this point of view, WordPress lock on MySQL is a good 
choice, because trying to support something else may become completely 
impossible via plain SQL statements parsing (i.e. how to convert that 
simple AUTO_INCREMENT into a sequence trigger).


-- 
Regards,
Justas B.

On 2012.11.19 20:43, Andrew Nacin wrote:
> I think we'd love a dbDelta() that doesn't suck. We've made a few
> performance-based improvements to it over the last few versions, but
> haven't gone beyond that.
>
> There's actually a newer parser in BackPress here:
> http://backpress.trac.wordpress.org/browser/trunk/includes/class.bp-sql-schema-parser.php.
> It has some issues, like being MySQL-version dependent in a few spots,
> ignoring blocks against global table upgrades, etc. If MySQL corrects a
> schema update to use a similar but different column type/definition, it'll
> keep trying to run the upgrade anyway. Not fun. (Peter Westwood (westi)
> could probably share more.)
>
> We're not beholden to that parser, though. We would welcome something that
> is backed with unit tests (and is testable, that'd be nice) and could pass
> muster at the scale WordPress sees, which is literally every MySQL
> configuration under the sun.