Skip to content
This repository has been archived by the owner on Apr 17, 2018. It is now read-only.

Custom type migration bugfix #45

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Custom type migration bugfix #45

wants to merge 2 commits into from

Conversation

jpr5
Copy link
Member

@jpr5 jpr5 commented Sep 9, 2011

Simple enough use case:

Json property needs more than 64k, so adjust the :length the same way you do Text's. b00m on migration.

My solution was to add an additional dm-migrations' Adapter#type_map lookup for property.class.superclass, before falling back to the underlying DM primitive.

This will solve the vast majority of cases, like Json < Text. It doesn't solve for any cases of inheritance depth from builtin type > 1: MoreThanJson < Json. (MoreThanJson.class.superclass won't be in Adapter#type_map's table.) I argue that a practical 99% is better than a real 0%.

More detailed explanation in both the commits and the integration spec I provided for dm-types.

FYI merging this pull will require 2 more steps:

  1. merge the 1-line change on custom_type_migration branch over at datamapper/dm-migrations (Fix bug related to migrating custom types derived from builtin types dm-migrations#31)
  2. revert commit e13b183, which was only necessary to show failing/passing specs across dm-types/dm-migrations

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.
@solnic
Copy link
Contributor

solnic commented Sep 13, 2011

@jpr5 just for the record, this issue will be addressed in 1.3.0. I'm working on the improved property API which is already merged in to master in dm-core, dm-types and dm-migrations (see my recent commits in those repos)

@jpr5
Copy link
Member Author

jpr5 commented Sep 13, 2011

@solnic That's great. Does that mean you're saying don't merge this pull request in the meantime? The fix itself is 1 line (in dm-migrations).

@solnic
Copy link
Contributor

solnic commented Sep 14, 2011

@jpr5 ok so as I commented on dm-migrations' pull request it's already merged in. I didn't merge this pull request though as the specs you added fail for me. Let's work this out for 1.2.1

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants