Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on May 19, 2010
  1. @dkubb

    Version bump to 1.0.0.rc1

    dkubb authored
  2. @dkubb

    Version bump to 0.0.0.rc1

    dkubb authored
  3. @dkubb

    Version bump to 0.0.0.1.0.0.rc1

    dkubb authored
  4. @dkubb

    Version bump to 0.0.0.rc1

    dkubb authored
  5. @dkubb
Commits on May 18, 2010
  1. @dkubb
  2. @dkubb
  3. @dkubb
  4. @dkubb
Commits on May 17, 2010
  1. @dkubb
Commits on May 14, 2010
  1. @dbussink
Commits on May 12, 2010
  1. @dbussink
  2. @dbussink
Commits on May 11, 2010
  1. @dkubb

    Updated all specs to use be(true) and be(false) instead of be_true an…

    dkubb authored
    …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
  2. @dkubb
Commits on May 10, 2010
  1. @dkubb
  2. @dkubb
  3. @dkubb
  4. @dkubb

    Change the use of String#demodulize to ActiveSupport::Inflector.demod…

    dkubb authored
    …ulize
    
    * 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.
  5. @solnic @dkubb

    Property and Type are now unified. Classes are organized in the follo…

    solnic authored dkubb committed
    …wing
    
    hierarchy:
    
    Property:
    
      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
  6. @shanna @dkubb

    Adapters act as query factory

    shanna authored dkubb committed
    [#1240 status:resolved]
Commits on May 3, 2010
  1. @snusnu

    Default to running specs using the in_memory adapter

    snusnu authored
    Running [bundle exec] rake spec will now use the
    in_memory adapter instead of raising an exception
  2. @snusnu
  3. @snusnu

    Added DataMapper::Adapters::AbstractAdapter.supports_transactions?

    snusnu authored
    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. @snusnu

    Added DataMapper::Adapters.adapter_name(const_name)

    snusnu authored
    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. @snusnu

    Control logging in specs via the LOG env variable

    snusnu authored
    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. @snusnu

    DataMapper::Spec.setup now performs adapter setup

    snusnu authored
    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
    snippets.
Commits on May 1, 2010
  1. @dkubb
Commits on Apr 30, 2010
  1. @snusnu

    Use DataMapper::Spec.setup for setting up spec runs

    snusnu authored
    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'
      DataMapper::Spec.setup
    
    and expects that to properly setup the connection.
    Once done, the current adapter is available via
    
      DataMapper::Spec.adapter
    
    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
    
      dm-*-adapter/spec/setup.rb
    
    file for any third party provided DM adapter.
    
    Adapter authors should have a look at
    
      dm-core/lib/dm-core/spec/setup
    
    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
    
      dm-*-adapter/spec/setup.rb
    
    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'
      DataMapper::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
    
      DataMapper::Spec.adapter
    
    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. @snusnu

    Use source 'http://rubygems.org'; in Gemfile

    snusnu authored
    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
  1. @snusnu
Commits on Apr 27, 2010
  1. @snusnu
  2. @snusnu
Commits on Apr 26, 2010
  1. @dkubb
  2. @dkubb
Something went wrong with that request. Please try again.