Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Sep 7, 2010
  1. @dkubb
Commits on Sep 2, 2010
  1. @dkubb

    Fixed default values to pass through Property#dump for DDL statements

    dkubb authored
    * This fixes various problems with Flag and Enum properties, among others,
      where the value that is provided in the :default option was used
      directly in the DDL statement. While this works when the ruby value
      maps onto the database column type, it does not work when Property#dump
      converts the value into another representation.
    [#1306 state:resolved]
    [#1320 state:resolved]
    [#1356 state:resolved]
Commits on Aug 25, 2010
  1. @dkubb
  2. @dkubb

    Stripped whitespace

    dkubb authored
  3. @postmodern @dkubb

    Added Migration#database, now with a deprecation warning to use #repo…

    postmodern authored dkubb committed
    …sitory instead.
  4. @postmodern @dkubb

    Dynamically setup the adapter when it is called from DataMapper::Migr…

    postmodern authored dkubb committed
  5. @postmodern @dkubb

    Extend DataMapper::Property::Lookup into SQL::TableCreator to solve a…

    postmodern authored dkubb committed
    … Property constant missing bug on Ruby 1.9.1.
  6. @postmodern @dkubb
  7. @postmodern @dkubb

    Do not print any output if there is no block set for the 'up' or 'dow…

    postmodern authored dkubb committed
    …n' actions of the migration.
  8. @postmodern @dkubb

    Do not override StandardError#initialize in DuplicateMigration.

    postmodern authored dkubb committed
    * Other libraries might want to use different messages.
  9. @postmodern @dkubb

    Moved DuplicateMigration out into dm-migrations/exceptions/duplicate_…

    postmodern authored dkubb committed
  10. @postmodern @dkubb

    Renamed DuplicateMigrationNameError to DuplicateMigration.

    postmodern authored dkubb committed
  11. @postmodern @dkubb

    Minor refactoring to DataMapper::Migration.

    postmodern authored dkubb committed
    * Deprecate the :database option in favor of the :repository option.
    * Only request the repository and adapter before actually performing
      the migration.
    * Initialize up_action and down_action to nil.
Commits on Jul 15, 2010
  1. @dbussink

    Put the Inflector into our own namespace

    dbussink authored
    It's not a sign of being a nice citizen that in case people don't
    use ActiveSupport, they end up with this constant defined anyway.
Commits on Jul 12, 2010
  1. @snusnu

    Oracle's 'ALTER TABLE' needs 'ADD' instead of 'ADD COLUMN'

    snusnu authored
    [#1357 state:resolved]
Commits on May 25, 2010
  1. @dkubb
Commits on May 24, 2010
  1. @dkubb
  2. @dkubb
Commits on May 22, 2010
  1. @dkubb

    Mixin the migration API into each loaded adapter

    dkubb authored
    * The previous approach relied on the adapters being setup, which
      may not always be true if bundler is being used. Sure, we could tell
      people to use :require => nil on adapters, but I would rather not have
      to explain that exception every-time this or related problems appear.
    * Even though this was not strictly related to #1280, I am tagging it
      with the bug because it is the exact same problem as with transactions
  2. @dkubb
Commits on May 10, 2010
  1. @solnic @dkubb

    Updated to the new property API

    solnic authored dkubb committed
  2. @dkubb

    Stripped whitespace

    dkubb authored
Commits on May 4, 2010
  1. @snusnu

    Makes DataMapper.auto_migrate_down!/up! @api semipublic

    snusnu authored
    These methods need to be overwritten in dm-constraints
    to perform down/up migration of foreign key constraints
Commits on May 3, 2010
  1. @snusnu

    Resolved require order dependency issues

    snusnu authored
    It is now possible to require 'dm-migrations'
    either before or after DataMapper.setup has been
    called, and the behavior will always be the same.
    The API for Repository and Model gets included right
    when the gem is required.
    If one or more adapters that support migrations
    are already set up, the API for these adapter(s)
    is included into all those adapters.
    In any case, a DataMapper::Adapters.const_added
    extension gets installed at the time that the gem
    gets required. This extension will make sure that
    the adapter related migrations API will get
    included into any new adapter that might get set
    up. This is guaranteed to happen if the newly set
    up adapter properly calls const_added(:AdapterName)
    after it was defined.
Commits on Apr 30, 2010
  1. @snusnu
  2. @snusnu
Commits on Apr 28, 2010
  1. @snusnu
Commits on Apr 9, 2010
  1. @snusnu
  2. @snusnu

    Register the adapter extensions during DataMapper.setup

    snusnu authored
    This means that it's not necessary anymore to require
    an explicit adapter before being able to use the
    automigration features. Previously it was necessary
    to do
      require 'dm-migrations/adapters/dm-mysql-adapter'
      DataMapper.setup(:default, 'mysql://localhost/fu')
    whereas all that's need now is
      require 'dm-migrations'
      DataMapper.setup(:default, 'mysql://localhost/fu')
    Calling DataMapper.setup will automatically require
    the dm-mysql-adapter and register the automigration
Commits on Apr 8, 2010
  1. @snusnu

    Imported migration related code from dm-core

    snusnu authored
    This means that the automigration features are now
    only available if dm-migrations along with at least
    one of the dm-xxx-adapter gems that support that
    feature, are required.
    Also, dm-migrations now holds the automigration
    related code for every adapter that supports the
    concept of automigration. This means that if
    adapter authors properly want to support this
    feature for their adapters, the code has to be
    put into dm-migrations.
Commits on Mar 20, 2010
  1. @snusnu

    [all] require 'dm-core' if a dm constant is used

    snusnu authored
    1) This is a workaround for current bundler which
       doesn't yet respect the order in which the gems
       have been declared in the Gemfile, when doing a
    2) Actually I also think it's good style to require
       all the code that we need in order to perform
       a task. Even if most applications will always
       require dm-core before requiring any of its
       plugins, it still doesn't hurt to be explicit
       and to avoid possible bugs in the first place.
Commits on Jan 8, 2010
  1. @snusnu
Commits on Nov 24, 2009
  1. @dkubb

    [dm-more] Converted to use Jeweler

    dkubb authored
    * Removed old/unecessary files
Commits on Nov 11, 2009
  1. @dkubb
Commits on Oct 7, 2009
  1. @dkubb

    [dm-migrations] Only merge in valid options from the primitive

    dkubb authored
    [#1069 state:resolved]
Something went wrong with that request. Please try again.