Changeset [317dcad677382c876ee9360ba662a56e2efc04c3] by Jordan Ritter

September 9th, 2011 @ 12:15 AM

Introduce failing specs for custom types migration bug.

When dm-migrations' dm-do-adapter runs, Adapter#property_schema_hash is invoked
on each property to generate the SQL for it.

For Property::Text, type_map[Property::Text] yields a schema of TEXT with no
:length property. When DM encounters a String primitive whose length exceeds the schema's capacity, it auto-adjusts the schema primitive to compensate
(i.e. in MySQL, {SHORT,MEDIUM,LONG}TEXT). Result: MEDIUMTEXT == AWESOME.

The case is different for (1) a custom Property derived from (2) a builtin
Property whose schema primitive changes based on the Property's size options.
For Property::Json, the first type_map[property.class] lookup is nil because
custom types can't/don't update Adapter#type_map -- custom properties can't know
what model/repository/adapter they're going to be on at definition time, which
they would need because the type_map is stored on the adapter class.

So, the second lookup type_map[property.primitive] kicks in, which for
Property::Json is type_map[String]. That in turn yields a schema of VARCHAR
with a :length property. As with Property::Text, when DM encounters a String
primitive whose length exceeds the schema's capacity, it auto-adjusts the schema
primitive to compensate (i.e. in MySQL, {SHORT,MEDIUM,LONG}TEXT). However, when
dm-migrations encounters any property_schema_hash with a :length option, it
automatically appends "(%i)" % length to the SQL statement. Result:
MEDIUMTEXT(123412341234) == entire migration FKD.
https://github.com/datamapper/dm-types/commit/317dcad677382c876ee93...

Committed by Jordan Ritter

  • A spec/fixtures/custom.rb
  • A spec/integration/custom_type_migration_spec.rb
New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »