[wp-hackers] RFC on a ticket on trac
jbutkus at time.ly
Wed Nov 21 15:55:27 UTC 2012
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).
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:
> 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.
More information about the wp-hackers