Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

table parser does not parse columns with only name and type. this leads to data loss over these column types during the copy phase/ #11

Closed
purzelrakete opened this Issue Feb 14, 2012 · 1 comment

Comments

Projects
None yet
1 participant
Contributor

purzelrakete commented Feb 14, 2012

Lhm::Table::Parser is used to parse the strucutre of origin and destination tables in a migration. The resulting intersection determines which columns are copied in the chunking phase.

Lhm::Table::Parser currently parses the output of show create table. An error in the regular expression for columns causes the following table definition to parse incorrectly:

CREATE TABLE users (
id int(11) NOT NULL AUTO_INCREMENT,
reference int(11) DEFAULT NULL,
username varchar(255) DEFAULT NULL,
group varchar(255) DEFAULT NULL,
created_at datetime DEFAULT NULL,
comment varchar(20) DEFAULT NULL,
description text,
PRIMARY KEY (id),
UNIQUE KEY index_users_on_reference (reference),
KEY index_users_on_username_and_created_at (username,created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

Parsing this ddl will fail to add the description column to the parsed table.

A more robust Table parser using information_schema and no regular expressions fixes this problem.

@ghost ghost assigned purzelrakete Feb 14, 2012

Contributor

purzelrakete commented Feb 17, 2012

fixed in 1.0.2

lgierth added a commit that referenced this issue Mar 3, 2012

jeffrafter pushed a commit to teespring/lhm that referenced this issue Feb 9, 2016

Merge pull request #11 from Shopify/test_for_detroying_single_row_whe…
…n_the_id_is_not_1_sc_master

Test for detroying single row when the id is not 1 sc master
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment