Rails transactions fail due to MyISAM instead of InnoDB tables

[btbonval]

Transaction blocks are expected to be ACIDic.

Atomic: the transaction occurs as a whole or not at all. Consistent: the transaction passes all applicable constraint checks. Isolation: one transaction should not interfere with any other concurrent transaction. Durability: a commit transaction persists.

Based on a number of tickets (#106, #129, and #132), there seem to be unexpected behavior surrounding transactions. In particular, atomic and isolated are the two of concern: transactions should occur in whole (or not at all) and without any chunk of the block simultaneously being operated on.

[btbonval]

106 and a subproblem discovered in #132 demonstrate that transaction blocks are not atomic. In both cases, a partial failure of the transaction leaves the database in an unsuitable state. Specifically, a temporary integer is set to 0, to be filled in by a value generated later on in the transaction. Upon failure of the partially completed transaction, the temporary integer is persisted instead of being rolled back as should happen.

129 might be either a problem of not being atomic (a failure breaks the code out before two tables are synchronized) or it might be a problem of isolation (two pieces of code are concurrently accessing and modifying the state of those two tables).

[btbonval]

This might be a problem of MySQL as well. My understanding is that MySQL has 3 database engines and only one performs proper relational database duties. The others are glorified spreadsheets. It would be worth testing transactions directly in the database to rule out MySQL as the point of failure.

[jywarren]

whoa... it never occurred to me that MySQL might not actually be capable of atomic transactions...

On Fri, Aug 23, 2013 at 7:42 PM, Bryan Bonvallet notifications@github.comwrote:

This might be a problem of MySQL as well. My understanding is that MySQL has 3 database engines and only one performs proper relational database duties. The others are glorified spreadsheets. It would be worth testing transactions directly in the database to rule out MySQL as the point of failure.

— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/issues/174#issuecomment-23197919 .

[btbonval]

There's a reason I hate on MySQL and lurve PosgreSQL, but that reason might be outdated by now. I'm told MySQL is just as good these days. Just want to make sure :) On Aug 24, 2013 12:40 AM, "Jeffrey Warren" notifications@github.com wrote:

whoa... it never occurred to me that MySQL might not actually be capable of atomic transactions...

On Fri, Aug 23, 2013 at 7:42 PM, Bryan Bonvallet notifications@github.comwrote:

This might be a problem of MySQL as well. My understanding is that MySQL has 3 database engines and only one performs proper relational database duties. The others are glorified spreadsheets. It would be worth testing transactions directly in the database to rule out MySQL as the point of failure.

— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/issues/174#issuecomment-23197919> .

— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/issues/174#issuecomment-23202892 .

[btbonval]

http://dev.mysql.com/doc/refman/5.0/en/ansi-diff-transactions.html "MySQL Server (version 3.23-max and all versions 4.0 and above) supports transactions with the InnoDB and BDB transactional storage engines. InnoDB provides full ACID compliance... The other nontransactional storage engines in MySQL Server (such as MyISAM) follow a different paradigm for data integrity..."

Although MyISAM is supposed to support integrity via atomicity, I wouldn't trust anything that tries to take shortcuts to be faster. It might be good to switch to InnoDB if it isn't already in use.

A whole page on the 10 different backend engines MySQL can use, for funsies (I think most are tailored for very special use cases): http://dev.mysql.com/doc/refman/5.0/en/storage-engines.html

[btbonval]

"MyISAM manages nontransactional tables. It provides high-speed storage and retrieval, as well as fulltext searching capabilities. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default." sigh. key words: nontransactional and default.

I'll check on this next time I get to a computer with my SSH keys to the plots system. Both to check for expected BEGIN / ROLLBACK / COMMIT behavior and to check for MyISAM vs InnoDB (those are the two most common backends unless something has changed in recent years).

[btbonval]

InnoDB is set to the default engine for tables on plots2 / publiclaboratory.

How to find engine used by table: http://stackoverflow.com/questions/213543/how-can-i-check-mysql-engine-type-for-a-specific-table

Parsing through InnoDB tables via SHOW TABLE STATUS WHERE engine LIKE 'innodb'; yields: images, node_selections, rsessions, rusers, schema_migrations, tag_selections, tags, user_selections.

SHOW TABLE STATUS WHERE engine NOT LIKE 'innodb' AND engine NOT LIKE 'myisam' returns no results, indicating any table other than the 8 above is MyISAM.

Will post results of transaction testing shortly. Need to check that my local database is similarly configured as I don't know if dump/restore maintains that metadata.

[btbonval]

My local database has the same engine configuration.

Using my local database, simulate Jeff unliking Somerville, Massachusetts with an error in the middle. Note at the rollback point, it says 0 rows affected even though a change had been made to the node table. Also note that the change persists after ROLLBACK.

Proof seems to be in this pudding that MyISAM does not support atomic transactions, so all tables but the 8 above will definitely not support transactions.

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT liking FROM node_selections WHERE user_id = 43229 AND nid = 178;
Empty set (0.00 sec)

mysql> SELECT liking FROM node_selections WHERE user_id = 1 AND nid = 178;
+--------+
| liking |
+--------+
|      1 |
+--------+
1 row in set (0.00 sec)

mysql> SELECT * FROM node WHERE nid = 178;
+-----+-------+-------+----------+---------------------------+-----+--------+------------+------------+---------+---------+----------+--------+------+-----------+--------------+
| nid | vid   | type  | language | title                     | uid | status | created    | changed    | comment | promote | moderate | sticky | tnid | translate | cached_likes |
+-----+-------+-------+----------+---------------------------+-----+--------+------------+------------+---------+---------+----------+--------+------+-----------+--------------+
| 178 | 15077 | place | en       | Somerville, Massachusetts |   1 |      1 | 1303168649 | 1374006208 |       0 |       0 |        0 |      0 |    0 |         0 |            1 |
+-----+-------+-------+----------+---------------------------+-----+--------+------------+------------+---------+---------+----------+--------+------+-----------+--------------+
1 row in set (0.00 sec)

mysql> UPDATE node SET cached_likes = 0;
Query OK, 2744 rows affected (0.12 sec)
Rows matched: 4279  Changed: 2744  Warnings: 0

mysql> THIS IS A FAKE ERROR TO ROLL BACK THE TRANSACTION!!
    -> ;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'THIS IS A FAKE ERROR TO ROLL BACK THE TRANSACTION!!' at line 1
mysql> NOW like.save! WON'T BE CALLED;
    '> ;
    '> '
    -> ;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'NOW like.save! WON'T BE CALLED;
;
'' at line 1
mysql> ROLLBACK;
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> SELECT cached_likes FROM node WHERE nid = 178;
+--------------+
| cached_likes |
+--------------+
|            0 |
+--------------+
1 row in set (0.00 sec)

[btbonval]

...because that's how you get ants!

[btbonval]

Quick confirmation that InnoDB tables do support rollback:

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT following FROM tag_selections WHERE user_id = 183615 AND tid = 6172;
+-----------+
| following |
+-----------+
|         1 |
+-----------+
1 row in set (0.00 sec)

mysql> UPDATE tag_selections SET following = 0 WHERE user_id = 183615 AND tid = 6172;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> ERRORSRS!
    -> ;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ERRORSRS!' at line 1
mysql> ROLLBACK;
Query OK, 0 rows affected (0.01 sec)

mysql> SELECT following FROM tag_selections WHERE user_id = 183615 AND tid = 6172;
+-----------+
| following |
+-----------+
|         1 |
+-----------+
1 row in set (0.00 sec)

[btbonval]

Alright so it looks like MyISAM does not support atomic transactions. The BEGIN, COMMIT and ROLLBACK are meaningless for any table using the MyISAM engine. The transactions do work for tables using the InnoDB engine, of which there are currently only 8.

We will want to convert MyISAM tables to InnoDB tables either

• specifically where we expect transactions, i.e. those tables affected by transactions currently in code
• all tables

My vote is for converting all tables. I don't know what kind of overhead or problems converting backends causes. The command comes from the reference:

ALTER TABLE t ENGINE = MYISAM;

(although we'd want to replace MYISAM with INNODB).

[btbonval]

Thanks to this link for inspiring a handy MyISAM to InnoDB converter without typing in each table name: http://stackoverflow.com/questions/6317966/can-alter-table-engine-innodb-be-run-on-multiple-tables-at-the-same-time

This command will generate a SQL statement which should be copy/pasted and fed back in as a command to convert all MyISAM tables to InnoDB.

SELECT CONCAT('ALTER TABLE ', table_name, ' ENGINE = INNODB;')
FROM information_schema.tables
WHERE table_schema LIKE 'publiclaboratory' AND engine LIKE 'myisam';

There are 188 such MyISAM tables. That's a lot of tables. Why so many tables? Is this from Drupal drippings?

[jywarren]

yes, drupal drippings. SO MANY TABLES SO LITTLE NEED. have you tried it on your local db? Are you running all tests on your local db, btw?

On Sat, Aug 24, 2013 at 4:44 PM, Bryan Bonvallet notifications@github.comwrote:

Thanks to this link for inspiring a handy MyISAM to InnoDB converter without typing in each table name:

http://stackoverflow.com/questions/6317966/can-alter-table-engine-innodb-be-run-on-multiple-tables-at-the-same-time

This command will generate a SQL statement which should be copy/pasted and fed back in as a command to convert all MyISAM tables to InnoDB.

SELECT CONCAT('ALTER TABLE ', table_name, ' ENGINE = INNODB;') FROM information_schema.tables WHERE table_schema LIKE 'publiclaboratory' AND engine LIKE 'myisam';

There are 188 such MyISAM tables. That's a lot of tables. Why so many tables? Is this from Drupal drippings?

— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/issues/174#issuecomment-23216237 .

[btbonval]

All the tests were on my local db, as I didn't want to make any permanent changes (accidental or on purpose) to the production database. I'm 95% confident that the tests on my local db should behave with the same results on the plots2 server, and that's good enough to reject a null hypothesis for most experiments! Granted my confidence is generated without any data.

The SQL command above generates text. I haven't tried it, but it won't damage anything. It's a SELECT operation. Its output is a series of ALTER TABLE xxx ENGINE = INNODB; commands. I wasn't sure if we wanted to modify all 188 tables or if we wanted to be a little more surgical about the operation. We might not need 188 ALTER TABLE xxx ENGINE = INNODB; commands. A few strategic ones might be all that is required, if we want to go that route.

Besides, my local system isn't running anything besides one or two web pages at a time. Making these changes to the production database will be different due to load, concurrent access to tables being modified, etc. I should try converting one or two tables from MyISAM to InnoDB on my local db to make sure nothing wonky happens, of course, but we'll probably want to try a small conversion test on the production server before going conversion crazy.

I was thinking we might want to try changing the node table over to InnoDB on the production system as an initial test case (after I make sure nothing wonky will happen on my local system). All the other tables with the Like stuff are InnoDB already; if I'm right about non-atomic transactions being the cause of like caching desync, changing node over to InnoDB should make the desync disappear. That'll be a nice Myth Confirmed.

Before doing anything like this on the production db, we'll want to back up the database. -Bryan

On Sat, Aug 24, 2013 at 5:52 PM, Jeffrey Warren notifications@github.comwrote:

yes, drupal drippings. SO MANY TABLES SO LITTLE NEED. have you tried it on your local db? Are you running all tests on your local db, btw?

On Sat, Aug 24, 2013 at 4:44 PM, Bryan Bonvallet notifications@github.comwrote:

Thanks to this link for inspiring a handy MyISAM to InnoDB converter without typing in each table name:

http://stackoverflow.com/questions/6317966/can-alter-table-engine-innodb-be-run-on-multiple-tables-at-the-same-time

This command will generate a SQL statement which should be copy/pasted and fed back in as a command to convert all MyISAM tables to InnoDB.

SELECT CONCAT('ALTER TABLE ', table_name, ' ENGINE = INNODB;') FROM information_schema.tables WHERE table_schema LIKE 'publiclaboratory' AND engine LIKE 'myisam';

There are 188 such MyISAM tables. That's a lot of tables. Why so many tables? Is this from Drupal drippings?

— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/issues/174#issuecomment-23216237> .

— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/issues/174#issuecomment-23219633 .

[btbonval]

On my local db:

mysql> ALTER TABLE node ENGINE = INNODB;
Query OK, 4279 rows affected (2.60 sec)
Records: 4279  Duplicates: 0  Warnings: 0

That was pretty quick (under 3 seconds) and my netbook is a piece of crap for IO.

I tried the thing from above where I modified cached_likes in node. It kooks like I can now roll back an error when Jeff tries to like Somerville. So that's good, transactions appear to rollback for the node table once it is converted to InnoDB. I also clicked around the web site a little bit to make sure pages still load; research notes and wikis could be read and modified.

mysql> SELECT cached_likes FROM node WHERE nid = 178;
+--------------+
| cached_likes |
+--------------+
|            0 |
+--------------+
1 row in set (0.04 sec)

mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql> UPDATE node SET cached_likes = 1 WHERE nid = 178;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> zOMG ERRORSZZ BEST ROLLBACK SOON;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'zOMG ERRORSZZ BEST ROLLBACK SOON' at line 1
mysql> ROLLBACK;
Query OK, 0 rows affected (0.01 sec)

mysql> SELECT cached_likes FROM node WHERE nid = 178;
+--------------+
| cached_likes |
+--------------+
|            0 |
+--------------+
1 row in set (0.00 sec)

[jywarren]

OK, sorry to have dropped the ball here -- so you think we can safely run ALTER TABLE on just the nodes table? Let's schedule a time maybe this week to give it a try... The db is backed up nightly and i usually dump a copy before attempting migrations anyways.

On Sat, Aug 24, 2013 at 10:08 PM, Bryan Bonvallet notifications@github.comwrote:

On my local db:

mysql> ALTER TABLE node ENGINE = INNODB; Query OK, 4279 rows affected (2.60 sec) Records: 4279 Duplicates: 0 Warnings: 0

That was pretty quick (under 3 seconds) and my netbook is a piece of crap for IO.

I tried the thing from above where I modified cached_likes in node. It kooks like I can now roll back an error when Jeff tries to like Somerville. So that's good, transactions appear to rollback for the node table once it is converted to InnoDB. I also clicked around the web site a little bit to make sure pages still load; research notes and wikis could be read and modified.

mysql> SELECT following FROM tag_selections WHERE user_id = 183615 AND tid = 6172; +-----------+ | following | +-----------+ | 1 | +-----------+ 1 row in set (0.00 sec)

mysql> SELECT cached_likes FROM node WHERE nid = 178; +--------------+ | cached_likes | +--------------+ | 0 | +--------------+ 1 row in set (0.04 sec)

mysql> BEGIN; Query OK, 0 rows affected (0.00 sec)

mysql> UPDATE node SET cached_likes = 1 WHERE nid = 178; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0

mysql> zOMG ERRORSZZ BEST ROLLBACK SOON; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'zOMG ERRORSZZ BEST ROLLBACK SOON' at line 1 mysql> ROLLBACK; Query OK, 0 rows affected (0.01 sec)

mysql> SELECT cached_likes FROM node WHERE nid = 178; +--------------+ | cached_likes | +--------------+ | 0 | +--------------+ 1 row in set (0.00 sec)

— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/issues/174#issuecomment-23220414 .

[btbonval]

Given backups and downtime, yeah I think changing the backend should be safe. Hopefully that particular table will help demonstrate solving some other problems, encouraging us to carry on with the rest of the tables. On Sep 23, 2013 11:36 AM, "Jeffrey Warren" notifications@github.com wrote:

OK, sorry to have dropped the ball here -- so you think we can safely run ALTER TABLE on just the nodes table? Let's schedule a time maybe this week to give it a try... The db is backed up nightly and i usually dump a copy before attempting migrations anyways.

On Sat, Aug 24, 2013 at 10:08 PM, Bryan Bonvallet notifications@github.comwrote:

On my local db:

mysql> ALTER TABLE node ENGINE = INNODB; Query OK, 4279 rows affected (2.60 sec) Records: 4279 Duplicates: 0 Warnings: 0

That was pretty quick (under 3 seconds) and my netbook is a piece of crap for IO.

I tried the thing from above where I modified cached_likes in node. It kooks like I can now roll back an error when Jeff tries to like Somerville. So that's good, transactions appear to rollback for the node table once it is converted to InnoDB. I also clicked around the web site a little bit to make sure pages still load; research notes and wikis could be read and modified.

mysql> SELECT following FROM tag_selections WHERE user_id = 183615 AND tid = 6172; +-----------+ | following | +-----------+ | 1 | +-----------+ 1 row in set (0.00 sec)

mysql> SELECT cached_likes FROM node WHERE nid = 178; +--------------+ | cached_likes | +--------------+ | 0 | +--------------+ 1 row in set (0.04 sec)

mysql> BEGIN; Query OK, 0 rows affected (0.00 sec)

mysql> UPDATE node SET cached_likes = 1 WHERE nid = 178; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0

mysql> zOMG ERRORSZZ BEST ROLLBACK SOON; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'zOMG ERRORSZZ BEST ROLLBACK SOON' at line 1 mysql> ROLLBACK; Query OK, 0 rows affected (0.01 sec)

mysql> SELECT cached_likes FROM node WHERE nid = 178; +--------------+ | cached_likes | +--------------+ | 0 | +--------------+ 1 row in set (0.00 sec)

— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/issues/174#issuecomment-23220414> .

— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/issues/174#issuecomment-24929145 .

[jywarren]

OK, i need to make more disk space available on publiclab.org but will run ALTER TABLE node ENGINE = INNODB; once i can make another backup.

On Mon, Sep 23, 2013 at 6:05 PM, Bryan Bonvallet notifications@github.comwrote:

Given backups and downtime, yeah I think changing the backend should be safe. Hopefully that particular table will help demonstrate solving some other problems, encouraging us to carry on with the rest of the tables. On Sep 23, 2013 11:36 AM, "Jeffrey Warren" notifications@github.com wrote:

OK, sorry to have dropped the ball here -- so you think we can safely run ALTER TABLE on just the nodes table? Let's schedule a time maybe this week to give it a try... The db is backed up nightly and i usually dump a copy before attempting migrations anyways.

On Sat, Aug 24, 2013 at 10:08 PM, Bryan Bonvallet notifications@github.comwrote:

On my local db:

mysql> ALTER TABLE node ENGINE = INNODB; Query OK, 4279 rows affected (2.60 sec) Records: 4279 Duplicates: 0 Warnings: 0

That was pretty quick (under 3 seconds) and my netbook is a piece of crap for IO.

I tried the thing from above where I modified cached_likes in node. It kooks like I can now roll back an error when Jeff tries to like Somerville. So that's good, transactions appear to rollback for the node table once it is converted to InnoDB. I also clicked around the web site a little bit to make sure pages still load; research notes and wikis could be read and modified.

mysql> SELECT following FROM tag_selections WHERE user_id = 183615 AND tid = 6172; +-----------+ | following | +-----------+ | 1 | +-----------+ 1 row in set (0.00 sec)

mysql> SELECT cached_likes FROM node WHERE nid = 178; +--------------+ | cached_likes | +--------------+ | 0 | +--------------+ 1 row in set (0.04 sec)

mysql> BEGIN; Query OK, 0 rows affected (0.00 sec)

mysql> UPDATE node SET cached_likes = 1 WHERE nid = 178; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0

mysql> zOMG ERRORSZZ BEST ROLLBACK SOON; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'zOMG ERRORSZZ BEST ROLLBACK SOON' at line 1 mysql> ROLLBACK; Query OK, 0 rows affected (0.01 sec)

mysql> SELECT cached_likes FROM node WHERE nid = 178; +--------------+ | cached_likes | +--------------+ | 0 | +--------------+ 1 row in set (0.00 sec)

— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/issues/174#issuecomment-23220414> .

— Reply to this email directly or view it on GitHub< https://github.com/jywarren/plots2/issues/174#issuecomment-24929145> .

— Reply to this email directly or view it on GitHubhttps://github.com/jywarren/plots2/issues/174#issuecomment-24931369 .

[btbonval]

mysql> ALTER TABLE node ENGINE = INNODB;
Query OK, 4493 rows affected (1.12 sec)
Records: 4493  Duplicates: 0  Warnings: 0

should fix node.vid = 0 problems of #132 and #165.

should fix node.cached_likes getting out of sync #129.

might fix partial node leftovers of #106.

[jywarren]

Renaming this issue since we've identified the problem.

[jywarren]

OK, i'm dealing with this in #181 because I want to wrap the whole migration in a transaction since we risk losing some tag data. Any future major database refinements that risk deletion of data can really benefit from a transaction around the whole thing, so I'm just changing all active tables to InnoDB.

https://github.com/jywarren/plots2/commit/fe8df1b62c5100328d1ee04657fab42598e3d8e2

[jywarren]

Ah, this is done now too as of https://github.com/jywarren/plots2/commit/fe8df1b62c5100328d1ee04657fab42598e3d8e2

[btbonval]

Definitely locks you into MySQL for the database backend software, which is why I would have rather left it as an IT thing and not a code thing.

however, glad to see it happened :)

On Mon, Jun 2, 2014 at 6:25 AM, Jeffrey Warren notifications@github.com wrote:

Ah, this is done now too as of fe8df1b https://github.com/jywarren/plots2/commit/fe8df1b62c5100328d1ee04657fab42598e3d8e2

— Reply to this email directly or view it on GitHub https://github.com/jywarren/plots2/issues/174#issuecomment-44836175.

[jywarren]

Ah, i see why you didn't do this in a transaction now. Well, if you want to wrap those lines of the migration in some kind of conditional, that sounds good. What's the equivalent for a postgres table type w transactions?

On Mon, Jun 2, 2014 at 11:12 AM, Bryan Bonvallet notifications@github.com wrote:

Definitely locks you into MySQL for the database backend software, which is why I would have rather left it as an IT thing and not a code thing.

however, glad to see it happened :)

On Mon, Jun 2, 2014 at 6:25 AM, Jeffrey Warren notifications@github.com wrote:

Ah, this is done now too as of fe8df1b < https://github.com/jywarren/plots2/commit/fe8df1b62c5100328d1ee04657fab42598e3d8e2>

— Reply to this email directly or view it on GitHub https://github.com/jywarren/plots2/issues/174#issuecomment-44836175.

— Reply to this email directly or view it on GitHub https://github.com/jywarren/plots2/issues/174#issuecomment-44849471.

[btbonval]

In postgres, the equivalent is "CREATE TABLE". ;)

PostgreSQL is an enterprise relational database system. There is only one engine, all tables are part of it, and it supports the full ACID feature set. There is no concept like table backends at all in pgsql.

On Mon, Jun 2, 2014 at 8:19 AM, Jeffrey Warren notifications@github.com wrote:

Ah, i see why you didn't do this in a transaction now. Well, if you want to wrap those lines of the migration in some kind of conditional, that sounds good. What's the equivalent for a postgres table type w transactions?

On Mon, Jun 2, 2014 at 11:12 AM, Bryan Bonvallet notifications@github.com

wrote:

Definitely locks you into MySQL for the database backend software, which is why I would have rather left it as an IT thing and not a code thing.

however, glad to see it happened :)

On Mon, Jun 2, 2014 at 6:25 AM, Jeffrey Warren notifications@github.com

wrote:

Ah, this is done now too as of fe8df1b <

https://github.com/jywarren/plots2/commit/fe8df1b62c5100328d1ee04657fab42598e3d8e2>

— Reply to this email directly or view it on GitHub https://github.com/jywarren/plots2/issues/174#issuecomment-44836175.

— Reply to this email directly or view it on GitHub https://github.com/jywarren/plots2/issues/174#issuecomment-44849471.

— Reply to this email directly or view it on GitHub https://github.com/jywarren/plots2/issues/174#issuecomment-44850427.

[btbonval]

<3 postgresql </3 mysql.

[jywarren]

good to know!

On Mon, Jun 2, 2014 at 12:29 PM, Bryan Bonvallet notifications@github.com wrote:

<3 postgresql </3 mysql.

— Reply to this email directly or view it on GitHub https://github.com/jywarren/plots2/issues/174#issuecomment-44859574.