* Minor spec description improvement
Running this task will create a Gemfile.local file that has all occurrences of :git sources replaced with local :path sources. The task assumes that your local dev directory structure matches the datmapper's github repository organization. So if you have all the repositories listed below the datamapper github account (or at least the ones listed in the Gemfile) in the same directory, it will probably work out of the box. If you want to exclude certain adapters because you don't have them installed, the rake task will recognize the EXCLUDED_ADAPTERS env var and comment out the adapter gems you listed. EXCLUDED_ADAPTERS=oracle,sqlserver rake create_local_gemfile will produce a Gemfile.local that won't setup these 2 adapters. You can run your bundle using the local Gemfile by setting the BUNDLE_GEMFILE env var before running any bundle command BUNDLE_GEMFILE=Gemfile.local bundle exec foo The dm-core repo has Gemfile.local added to its .gitignore file, so you'll never run any risks of accidentally checking in a Gemfile that contains your local development paths.
The various adapters are now available via the dm-xxx-adapter repos below the datamapper account on github. The auto_migrate!/auto_upgrade! functionality is now only available in case dm-migrations gets required. In order to get a datamapper application up and running along with automigrations, do the following: require 'dm-core' #optional require 'dm-migrations' DataMapper.setup(:default, 'mysql://localhost/fu') # model definitions ... DataMapper.auto_migrate! Failing to require dm-migrations will result in undefined method `auto_migrate!' for DataMapper:Module (NoMethodError) From this commit on, dm-core does not provide any adapters apart from the abstract and in_memory adapters. This means that from now on, users will need to depend on any of the datamapper/dm-xxx-adapter gems in order to be able to connect to the database of their choice. If automigration facilities are desired, it's necessary to also depend on and require dm-migrations. Unfortunately, the way dm-core's shared adapter specs are currently written doesn't lend itself nicely to the way we want to use them from the various extracted dm-xxx-adapters. Because we lazily require the desired adapter only when DataMapper.setup is called, we cannot require the shared examples before doing so. This is because the shared adapter spec relies on the adapter class to already be known at the time it gets read in. It relies on that because it checks if the various adapter methods like :create, :update etc are supported by the adapter under test. To workaround this, you can use ADAPTER_SUPPORTS=all bundle exec rake spec to run specs for the various dm-xxx-adapter gems. A proper fix for this issue would be to write the shared adapter specs in such a way, that they evaluate the adapter possibilities only at runtime and not immediately when the file gets read in.
* This is due to a change in RSpec where be_true now passes with any object, except false or nil. be_false will pass with the false or nil, and fail with everything else. More information on the change: https://rspec.lighthouseapp.com/projects/5645/tickets/931 While I can understand why this change was made, any place in the specs where be_true and be_false was specified, the intention was to assert that either true or false *only* was being returned; we wanted the spec to fail if nil or any other object was returned.
* In MRI Module#undef_method accepts 0 or more method names, and removes them all. In JRuby it accepts only 1 method name. The documentation shows that only 1 method name should be provided, so JRuby matches the docs, while MRI has a much looser contract. DM was using the MRI API, but this has been changed to match the documented behaviour, and should work in JRuby. [#1229 state:resolved]
* The only behavior these two classes share is that #rollback returns self. Other than that, they are completely different, and not just in their implementations, but conceptually too. I'm not sure what I was thinking by inheriting Immutable from the Transient state.
* Added documentation to persisted state related methods * Moved initialization of Resource#persisted_state out of Resource#initialize since it's now set lazily
* Simplifies logic for lazy loading, getting, setting, saving and deleting resources. Instead of conditionals throughout DM that performs different things for these operations based on the state of the Resource, the logic is centralized in the Resource::State objects.
* Added ability to force Model#assert_valid to run even when the model had been previously initialized.
* The purpose of this change is to allow the methods to be called directly from external objects. A future refactoring will add objects that carry out creation, updating and executing hooks in the correct order, and these explicit hook methods will be necessary to allow calling things in the correct order. * This code will mostly be refactored in the future, as Resource will no longer be responsible for actually carrying out persistence operations. * Refactored persistence hooks to not use AOP style hooking * Ensure hooks can be inherited properly by subclasses * Update persistence methods to allow throwing :halt to stop persistence * Allow hooks to be copied to other models
From now on, dm-core itself doesn't provide any support for transactions. If you use transactions in your applications, please require the dm-transactions gem to be able to use the same API as before.
Having this code available in a method that can be required from other plugins, makes the last two remaining spec errors in dm-transactions go away.
dm-transactions specs need the shared resource spec and the shared SEL spec which in turn use the pending and collection helpers and the counter adapter.