Commits on May 20, 2010
Commits on May 19, 2010
  1. Bumped gem deps to latest versions

    dkubb committed May 19, 2010
  2. Version bump to 1.0.0.rc2

    dkubb committed May 19, 2010
  3. Version bump to 1.0.0.rc1

    dkubb committed May 19, 2010
  4. Version bump to 0.0.0.rc1

    dkubb committed May 19, 2010
  5. Version bump to

    dkubb committed May 19, 2010
  6. Version bump to 0.0.0.rc1

    dkubb committed May 19, 2010
Commits on May 18, 2010
Commits on May 17, 2010
Commits on May 14, 2010
Commits on May 12, 2010
Commits on May 11, 2010
  1. Updated all specs to use be(true) and be(false) instead of be_true an…

    dkubb committed May 11, 2010
    …d be_false
    * It looks like a few specs were missed in the property refactor, so
      updated them to match the rest of the project
Commits on May 10, 2010
  1. Change the use of String#demodulize to ActiveSupport::Inflector.demod…

    dkubb committed May 10, 2010
    * We are trying not to use the String extensions for the inflections
      because we want to try to minimize the number of core/stdlib classes
      that we affect when using AS. Ideally we would not affect any, and I
      think this is a good long term goal, but for now we just don't want
      to make it worse.
  2. Property and Type are now unified. Classes are organized in the follo…

    solnic committed with dkubb May 5, 2010
      Binary   < String
      Boolean  < Object
      Class    < Object
      Date     < Object
      DateTime < Object
      Decimal  < Numeric
      Float    < Numeric
      Integer  < Numeric
      Numeric  < Object
      Object   < Property
      String   < Object
      Text     < String
      Time     < Object
      Discriminator < Class
      Serial        < Integer
    Important changes:
      * All the type-specific options and typecast methods are located in the
        corresponding subclasses and shared modules
      * Primitive can be set to any class
      * Property.accept_options is used to define which options the property
        constructor accepts
      * Predefined property options are inherited down the hierarchy
      * A predefined option can be overridden when declaring a property on a model
      * Validation-specific code has been moved to dm-validations
      * Paranoid types have been moved to dm-types
      * DataMapper::Type is now deprecated
  3. Adapters act as query factory

    shanna committed with dkubb Apr 12, 2010
    [#1240 status:resolved]
Commits on May 3, 2010
  1. Default to running specs using the in_memory adapter

    snusnu committed May 3, 2010
    Running [bundle exec] rake spec will now use the
    in_memory adapter instead of raising an exception
  2. Revert "Added DataMapper::Adapters::AbstractAdapter.supports_transact…

    snusnu committed May 3, 2010
    This reverts commit 4443bd3.
  3. Added DataMapper::Adapters::AbstractAdapter.supports_transactions?

    snusnu committed May 3, 2010
    This is a semipublic api addition that is at least
    used in dm-transactions for now. It returns false
    in the case of AbstractAdapter and is overwritten
    to return true in DataObjectsAdapter.
    This will make it easier to discover if it is
    necessary to include transaction related behavior
    in case dm-transactions is loaded and a new adapter
    gets set up.
    Also, this allows other plugins to easily discover
    if they need to take special measures in case the
    adapter in use supports transactions.
  4. Added DataMapper::Adapters.adapter_name(const_name)

    snusnu committed May 3, 2010
    This is a semipublic api addition that is used at
    least in dm-transactions for now. It seems like a
    natural counterpart to the #adapter_class method
    that looks up the adapter class based on the adapter
    name (as returned by this newly added method).
  5. Control logging in specs via the LOG env variable

    snusnu committed May 2, 2010
    By default, no logging happens, however, it can be
    turned on by specifying certain values for the
    LOG environment variable
      LOG=file          # "#{Dir.pwd}/spec/log/dm.log"
      LOG=anything_else # $stdout
    This works for dm-core and all adapters and plugins
    that make use of 'dm-core/spec/setup.rb'
  6. DataMapper::Spec.setup now performs adapter setup

    snusnu committed May 2, 2010
    The following methods on DataMapper::Spec now
    delegate directly to the instance methods on the
    currently used spec adapter.
      DataMapper::Spec.setup    # setup and memoize
      DataMapper::Spec.setup!   # always call setup
      DataMapper::Spec.adapter  # same as setup
    If the ADAPTER and PLUGINS haven't been configured
    at the time one of these methods is invoked, it
    will be configured before proceeding with setup.
    This cuts down the number of code necessary to get
    specs with any adapter and plugin combination up
    and running. All that needs to be done is
      require 'dm-core/spec/setup'
      DataMapper::Spec.setup # or .adapter
    at the appropriate time, in specs or standalone
Commits on May 1, 2010
Commits on Apr 30, 2010
  1. Use DataMapper::Spec.setup for setting up spec runs

    snusnu committed Apr 23, 2010
    Support for the ADAPTERS env variable, and thus for
    running specs on multiple adapters with one command,
    has been dropped with this commit. Running specs is
    now limited to a single adapter at a time. Time
    has shown that this is the only reasonable way to
    run the specs during development. Possible CI tools
    can of course still maintain a list of available
    adapters and run specs for each of those separately.
    Additionally, this commit forms the base of being
    able to run dm-core specs on any of the available
    adapters, using any of the available plugins, simply
    by switching the ADAPTER and PLUGINS env variables.
    Effectively, dm-core's spec_helper.rb now does
      require 'dm-core/spec/setup'
    and expects that to properly setup the connection.
    Once done, the current adapter is available via
    To achieve that, dm-core now provides a base spec
    adapter class, located in dm-core/spec/setup.rb,
    that makes it very easy to write a
    file for any third party provided DM adapter.
    Adapter authors should have a look at
    and at the various dm-*-adapter/spec/setup.rb files
    below the datamapper github account, to get an idea
    for how to write such a file.
    Third party adapter authors are encouraged to
    update their adapters and provide a
    file. Providing this file makes it possible for
    dm-core to run its full specsuite on the adapter,
    which is a quite solid test for any adapter out
    there (and of course dm-core itself). The way it's
    done is that basically, dm-core issues a
      require "dm-#{ENV['ADAPTER']}-adapter/spec/setup"
    during the course of DataMapper::Spec.setup.
    Furthermore, this commit forms the base for
    simplifying spec_helper.rb files among all of the
    dm-* gems. Again, all that needs to be done to
    run any plugin's specs against any of the available
    adapters, is to add
      require 'dm-core/spec/setup'
    to the plugin's spec_helper.rb file. This will
    make sure that the desired adapter is setup, and
    the specs are ready to go. As with dm-core itself,
    the current adapter is available via
    and of course the PLUGINS env variable is recognized
    too, so if plugin specs should run using other
    plugins enabled, simply run the spec command with
    something like
      PLUGINS=dm-constraints,... bundle exec rake spec
    and DataMapper::Spec.setup will require the plugins
    for you.
    Last but not least, to provide a uniform (database)
    naming scheme for spec runs, we decided that we will
    default to
      username: datamapper
      password: datamapper
      database: datamapper_default_tests
      database: datamapper_alternate_tests
    Make sure you have these databases setup with the
    appropriate privileges on every adapter that you
    plan to run dm-core specs on. We need two databases
    because datamapper allows to work with two of them
    at a time and contains specs for doing that.
  2. Use source '' in Gemfile

    snusnu committed Apr 30, 2010
    Because wycats' take on this is that using a symbol
    only obscures useful info for very little gain.
    And because I didn't want to go ahead and change
    all other dm-* gems too.
Commits on Apr 28, 2010