* 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]
… Property constant missing bug on Ruby 1.9.1.
…n' actions of the migration.
* Other libraries might want to use different messages.
* 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 [#1280]
These methods need to be overwritten in dm-constraints to perform down/up migration of foreign key constraints
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.
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 extensions
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.
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 Bundler.require 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.