Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The Drizzle database engine, an in-depth refactor of the MySQL engine, is the next big thing in the relational database engine, especially on the cloud.
Let's make sure it is on our radar.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 809810.patch | 7.92 KB | Damien Tournoud |
| #1 | 809810.patch | 7.04 KB | Damien Tournoud |
Comments
Comment #1
Damien Tournoud CreditAttribution: Damien Tournoud commentedThis allows Drupal 7 to install on recent versions of Drizzle (those non affected by bug #310344), and pass 99% of the database tests.
Two obvious things we need to fix:
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedComment #3
stewartsmith CreditAttribution: stewartsmith commentedWe don't do SHORT/MEDIUM/LONG TEXT we just have TEXT. Same for BLOB, so the type map in the patch will need that fixed (I'm 99% sure we don't have the aliases in the parser...)
We are also utf8 and the same index size limits apply for innodb as on mysql (I've seen Drupal bugs fixed for this in the past year).
Awesome to see progress on this too!
--
Stewart (Drizzle hacker)
Comment #4
stewartsmith CreditAttribution: stewartsmith commentedThe index length was fixed in the latest tarball (see https://bugs.launchpad.net/drizzle/+bug/578842).
In Drizzle we can have up to 4byte utf8, I've fixed things in Drizzle so that as of now you can have pretty much the same limits as MySQL's 3byte UTF8. You may still run into the 3500byte limit in indexes for really big indexes, but if you're hitting that, you're probably doing something wrong :)
Comment #5
Damien Tournoud CreditAttribution: Damien Tournoud commentedStewart: nice of you to show around like this :)
The TEXT and BLOB types obviously wrong. I guess we simply don't use them, because I haven't bumped into that during cursory testing.
I saw the fix to the index length limit, that was a pretty much needed one.
What about the concatenation operator? Are there plans to restore the double pipe?
Comment #6
Damien Tournoud CreditAttribution: Damien Tournoud commentedNew patch. Here are the tests that currently fail:
(the file fails are probably due to my crude fix in
system_cron())Comment #7
stewartsmith CreditAttribution: stewartsmith commentedThere's the CONCAT() function. IIRC the double pipe causes a bunch of shift/reduce conflicts in the parser (which isn't good for general performance)... may want to ask on the mailing list though, somebody else may remember better than me.
Comment #8
andypostConcat() considered to be implemented as function, so for now it's not possible. see #809698: Refrain from using the || operator for concatenation
Comment #9
Damien Tournoud CreditAttribution: Damien Tournoud commented@andypost: not sure what you mean. CONCAT() is built-in in both MySQL and Drizzle. All other core engines have implemented it as UDF (both PostgreSQL and SQLite).
Comment #10
Damien Tournoud CreditAttribution: Damien Tournoud commentedAs of today, here is what fails:
Comment #11
Damien Tournoud CreditAttribution: Damien Tournoud commentedOk, so:
That's because Drizzle doesn't support the TIME type anymore. This test just cannot pass (I told you this test wasn't a good idea!).
That's because:
information_schema.tables.table_commentcolumn anymore. Not sure if that's intentional or not, because the information_schema is completely broken on my current version of Drizzle.That's because the test is dumb, and assumes that the database engine will silently truncate numeric fields. Drizzle doesn't silently truncate *anything*. I guess we can fix that in #851602: FieldCrudTestCase::testUpdateField() does not test changing the schema.
That's because the
information_schema.tablesdoesn't work at all on my version of Drizzle.Not sure why those fail, I guess that's related to the
information_schema.tablesfailure.Comment #12
brianaker CreditAttribution: brianaker commentedHave you tried since we restored the Information Schema? It was removed while we reworked it to follow the ANSI SQL standard.
Thanks!
Comment #13
stewartsmith CreditAttribution: stewartsmith commentedIt's not in INFORMATION_SCHEMA in Drizzle as TABLE_COMMENT is not in the standard. It was a MySQL extension (see http://dev.mysql.com/doc/refman/5.0/en/tables-table.html). It is accessible through the DATA_DICTIONARY.TABLES table though:
drizzle> create table t1 (a int) comment="hello world";
Query OK, 0 rows affected (0 sec)
drizzle> select * from data_dictionary.tables where table_name="t1";
+--------------+------------+------------+--------+------------+-----------------+--------------------------+--------------------------+---------------+
| TABLE_SCHEMA | TABLE_NAME | TABLE_TYPE | ENGINE | ROW_FORMAT | TABLE_COLLATION | TABLE_CREATION_TIME | TABLE_UPDATE_TIME | TABLE_COMMENT |
+--------------+------------+------------+--------+------------+-----------------+--------------------------+--------------------------+---------------+
| test | t1 | STANDARD | InnoDB | DEFAULT | utf8_general_ci | Tue Sep 28 08:14:42 2010 | Tue Sep 28 08:14:42 2010 | hello world |
+--------------+------------+------------+--------+------------+-----------------+--------------------------+--------------------------+---------------+
1 row in set (0.02 sec)
Why is getting the table comment important? Perhaps there is a better way?
Comment #14
pwolanin CreditAttribution: pwolanin commentedAnyone tried this with the GA release? Should this be made a contrib project for 7, or something we can backport to core?
Comment #15
renat CreditAttribution: renat commentedSubscribe.
Comment #17
RobLoachI'm with pwolanin here. This might live better as a contrib project for both 7 and 8.
Comment #18
basic CreditAttribution: basic commentedI believe it is important for this support to be part of 8.x core. I can understand a contrib for 7.x, but not for 8.x.
Comment #19
judahtanthony CreditAttribution: judahtanthony commentedI tried the drizzle patch installing Drupal 7. It is failed to insert records because batch (and other tables) use the field name timestamp (which I think is a reserved word in Drizzle). I overwrite the __toString magic method in the drizzle query class to wrap the field name with "`", which got all the data in there, but then the first select statement the requested the 'timestamp' field fails.
Seeing as select queries are passed in as a strings (instead of generated by a class) I'm not sure how to quote the field names. I played around with regex, but it seems fragile, inefficient and hacky.
I can't convince all "table owners" to rename your timestamp fields something other than "timestamp", can I? ;)
Comment #20
judahtanthony CreditAttribution: judahtanthony commentedConfirmed. Drizzle is a fork of MySQL 6.
http://dev.mysql.com/doc/mysqld-version-reference/en/mysqld-version-refe...
. . . indicates that "timestamp" is a reserved word as of MySQL 5.6. We should REALLY consider changing the db table field names if it will conflict with the latest MySQL.
Comment #21
marcingy CreditAttribution: marcingy commentedThis should still be against d8 as that is where things are done first
Comment #22
pwolanin CreditAttribution: pwolanin commentedtimestamp has long been on this list:
http://drupal.org/node/141051
So really that should not have been used as a column name for a long time.
A good 1st step might also be to add this list to coder?
Comment #31
longwaveDrizzle's last release was 2012 and the project was abandoned in 2016: https://en.wikipedia.org/wiki/Drizzle_(database_server)