…es which sql dialect it needs (for migrations) * use the dialect method to determine the right sql-extension for the adapter * adjusted specs and added one spec to reflect above changes
* 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]
* While yaml has some limited support for migrations, it is not complete and in_memory has none. Future updates may include methods for these adapters, but for now migrations should be considered unsupported for these adapters.
Specs for in_memory and yaml still fail, but at least they're running now. Previously they bailed out immediately because of calling  (lambda.call) on nil. This (like many other dm-migrations specs) looks kinda weird and will probably be refactored soonish
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.