Permalink
Commits on Apr 3, 2012
  1. Added Migration#select.

    committed Apr 3, 2012
Commits on Feb 9, 2012
Commits on Nov 16, 2011
  1. Remove VERSION file

    solnic committed Nov 16, 2011
Commits on Nov 7, 2011
  1. Remove jeweler

    solnic committed Nov 7, 2011
Commits on Oct 15, 2011
  1. Bump version to 1.3.0.beta

    solnic committed Oct 15, 2011
  2. Merge branch 'release-1.2'

    Conflicts:
    	lib/dm-migrations/adapters/dm-do-adapter.rb
    solnic committed Oct 15, 2011
Commits on Oct 9, 2011
  1. Version bump to 1.2.0

    solnic committed Oct 9, 2011
  2. Merge pull request #33 from miegs3/master

    Allowing bytea columns to migrate by ignoring length
    solnic committed Oct 9, 2011
Commits on Oct 4, 2011
Commits on Sep 14, 2011
  1. Merge pull request #13 from maxsum-corin/master

    Wrong quotes in field_exists? for sqlserver
    solnic committed Sep 14, 2011
  2. Version bump to 1.2.0.rc2

    solnic committed Sep 14, 2011
  3. Fix bug related to migrating custom types derived from builtin types.

    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.
    jpr5 committed with solnic Sep 9, 2011
Commits on Sep 13, 2011
  1. Merge remote-tracking branch 'origin/master' into custom_type_migration

    Conflicts:
    
        lib/dm-migrations/adapters/dm-do-adapter.rb
    
            Resolved by taking master and re-adding property.class.superclass
            lookup.
    jpr5 committed Sep 13, 2011
Commits on Sep 12, 2011
Commits on Sep 9, 2011
  1. Fix bug related to migrating custom types derived from builtin types.

    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.
    jpr5 committed Sep 9, 2011
Commits on Sep 5, 2011
  1. Regenerated gemspec

    solnic committed Sep 5, 2011
  2. Bump version in Gemfile

    solnic committed Sep 5, 2011
  3. Version bump to 1.2.0.rc1

    solnic committed Sep 5, 2011
Commits on Sep 1, 2011
  1. Upgraded gem dependencies

    dkubb committed Sep 1, 2011
  2. Stripped whitespace

    dkubb committed Sep 1, 2011
Commits on Aug 8, 2011
  1. Add support to specify table options when creating a table via migrat…

    …ions. (For things like specifying MySQL storage engines, etc)
    nevir committed with xaviershay Mar 22, 2011
Commits on Aug 2, 2011
Commits on Aug 1, 2011
  1. Add Rakefile to examples

    ericgj committed Aug 1, 2011
Commits on Jul 2, 2011
  1. Respect repository scope when specified.

    Previously, given configured repositories :a and :b, auto_{upgrade,migrate}!(:a)
    would affect :b also.
    jpr5 committed Jul 2, 2011
Commits on Jun 17, 2011
  1. Use the property class methods instead of the DEFAULT_* constants

    * When the Property::String.length is overridden the constant value will not
      update, and will be (incorrectly) used in the migration.
    * Stop memoizing the type_map to allow overridden property options to be
      used.
    dkubb committed Jun 17, 2011
  2. Minor whitespace fixes

    dkubb committed Jun 17, 2011