Commits on Apr 12, 2010
  1. @dkubb
  2. @dkubb
  3. @dkubb
  4. @dkubb

    Deprecated BigDecimal type in favour of Decimal property type

    * Minor spec description improvement
    dkubb committed Apr 12, 2010
Commits on Apr 10, 2010
  1. @snusnu
Commits on Apr 9, 2010
  1. @snusnu

    Added "rake create_local_gemfile" task

    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.
    snusnu committed Apr 9, 2010
  2. @snusnu

    Extracted adapter and migration code and specs

    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.
    snusnu committed Apr 9, 2010
  3. @dkubb

    Simplified MethodCommand#call

    dkubb committed Apr 9, 2010
  4. @dkubb

    Changed usage of be_true and be_false in specs to be(true) and be(false)

    * 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.
    dkubb committed Apr 9, 2010
  5. @dkubb

    Minor fix to spec comments

    dkubb committed Apr 8, 2010
  6. @dkubb

    Minor spelling fix

    dkubb committed Apr 8, 2010
Commits on Apr 8, 2010
  1. @dkubb
Commits on Apr 7, 2010
  1. @dkubb

    Fixed invalid usage of Module#undef_method

    * 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]
    dkubb committed Apr 7, 2010
  2. @dkubb
  3. @dkubb

    Do not inherit State::Immutable from State::Transient

    * 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.
    dkubb committed Apr 6, 2010
Commits on Apr 6, 2010
  1. @dkubb

    Set Resource#persisted_state to default to a 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
    dkubb committed Apr 6, 2010
  2. @dkubb

    Refactored persistence layer to use a state machine

    * 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.
    dkubb committed Mar 24, 2010
Commits on Apr 5, 2010
  1. @snusnu
  2. @dkubb

    Force assert_valid to be called by migrations

    * Added ability to force Model#assert_valid to run even when the model
      had been previously initialized.
    dkubb committed Apr 4, 2010
Commits on Apr 3, 2010
  1. @dkubb
Commits on Apr 2, 2010
  1. @dkubb
  2. @dkubb

    Minor spec simplification

    dkubb committed Apr 1, 2010
  3. @dkubb
  4. @dkubb
  5. @dkubb

    Regenerated gemspec

    dkubb committed Apr 1, 2010
  6. @dkubb
  7. @snusnu
Commits on Apr 1, 2010
  1. @dkubb
  2. @dkubb
  3. @dkubb

    Split up hooks into explicit methods

    * 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
    dkubb committed Mar 22, 2010
  4. @snusnu
  5. @snusnu

    Moved transaction related code to dm-transactions

    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.
    snusnu committed Mar 30, 2010
  6. @snusnu

    Makes global model cleanup code available to plugins

    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.
    snusnu committed Apr 1, 2010
  7. @snusnu

    Allow to require more spec stuff from plugins

    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.
    snusnu committed Apr 1, 2010
  8. @dkubb