Skip to content
Commits on Mar 2, 2011
  1. @dkubb

    Version bump to 1.1.0.rc2

    dkubb committed Mar 1, 2011
  2. @dkubb

    Updated Gemfile and gemspec

    dkubb committed Mar 1, 2011
Commits on Mar 1, 2011
  1. @dkubb
  2. @dkubb

    Updated yard dependency to ~> 0.6

    dkubb committed Feb 28, 2011
  3. @dkubb

    Updated rcov dependency to 0.9.9

    dkubb committed Feb 28, 2011
  4. @dkubb
  5. @dkubb

    Updated Copyright year

    dkubb committed Feb 28, 2011
  6. @dkubb

    Version bump to 1.1.0.rc1

    dkubb committed Feb 28, 2011
Commits on Feb 28, 2011
  1. @dkubb

    Regenerated gemspec

    dkubb committed Feb 27, 2011
  2. @dkubb
Commits on Feb 26, 2011
  1. @dbussink

    Refactor properties and relationships to use a single module

    This prevents having a very large number of anonymous modules
    attached to a model. All these anonymous models harm performance
    because of slower method lookup. It also makes the behavior when
    reopening a model and redefining a property more consistent. The
    latter actually happens a lot in the specs.
    
    This was found wheni debugging the JIT issue with Rubinius.
    dbussink committed Feb 26, 2011
Commits on Feb 22, 2011
  1. @dkubb

    Simplify relationship finalization

    * Using a case statement here won't necessarily work because the
      OneToMany object is a proxy object, and the Relation#=== methods
      are inherited from Class#===, and don't know anything about the
      proxy object. The best approach is to use kind_of? and only
      handle the 3 distinct cases:
    
        1. The relationship is m:1
        2. The relationship is m:m (or 1:1 wrapping a m:m)
        3. The relationship is 1:m (or 1:1 wrapping a 1:m)
    dkubb committed Feb 21, 2011
  2. @dkubb
Commits on Feb 21, 2011
  1. @solnic

    Cleaned up my previous commit

    solnic committed Feb 21, 2011
  2. @solnic
  3. @dkubb

    Make sure all specs require spec_helper

    * On some platforms, where the specs are run in a different order, this
      was causing problems because the specs that didn't require spec_helper
      were being executed first, and the environment wasn't setup properly
      for them. However, on OSX (where I test primarily) the spec_helper is
      required at some earlier point in time.
    
      This should never happen. A spec should be able to run stand-alone, and
      in any order and always return the same results.
    dkubb committed Feb 20, 2011
  4. @dkubb

    Require spec_helper using a relative path

    * This silences a JRuby warning
    dkubb committed Feb 20, 2011
Commits on Feb 20, 2011
  1. @jpr5

    Don't ever use String#to_datetime because it's broken in AS < 3.x.

    Tested 2.3.3 and 2.3.11 (latest as of this commit):
    
    ruby> ActiveSupport::VERSION::STRING
    => "2.3.11"
    ruby> "2010-01-01 00:00:00 -0800".to_datetime
    => Fri, 01 Jan 2010 00:00:00 +0000    # TZ gone
    
    ruby> DateTime.parse("2010-01-01 00:00:00 -0800")
    => Fri, 01 Jan 2010 00:00:00 -0800    # TZ preserved
    jpr5 committed Feb 20, 2011
Commits on Feb 19, 2011
  1. @dkubb

    Added i18n dependency

    dkubb committed Feb 19, 2011
Commits on Feb 18, 2011
  1. @dkubb

    Updated activesupport dep to 3.0.4

    dkubb committed Feb 17, 2011
  2. @dkubb

    Updated gemspec

    * Removed duplicate deps specified in Rakefile
    dkubb committed Feb 17, 2011
  3. @dkubb

    Changed jeweler dep to 1.5.2

    * Removed check_dependencies task as a dep on the spec/rcov rake tasks
    dkubb committed Feb 17, 2011
Commits on Feb 8, 2011
  1. @snusnu

    Make DataMapper::Model.new a private API for now

    This method is mainly used inside DM to generate
    anonymous join models. It was never really meant
    to be public API and we actually already started
    questioning the meaning of semipublic API.
    If a method is intended to be called by clients,
    it's public API, if not it should be private API.
    snusnu committed Feb 9, 2011
Commits on Jan 24, 2011
  1. @dkubb
  2. @dkubb
  3. @xaviershay
Commits on Jan 21, 2011
  1. @xaviershay

    Ruby 1.8 doesn't support Range#cover?, use Range#include? instead - i…

    …n this case they are equivalent
    xaviershay committed Jan 21, 2011
  2. @xaviershay
  3. @xaviershay

    Allow Query::Path objects to be specified for the order of a query. For

    example:
    
      Post.all(
        :order => author.full_name,
        :links => [Post.relationships['author'].links]
      )
    xaviershay committed Jan 11, 2011
  4. @xaviershay

    Relax the valid order assertions to allow ordering by properties not on

    the base model, for example:
    
      Post.all(
        :order => Author.full_name,
        :links => Post.relationships['author'].links]
      )
    xaviershay committed Jan 11, 2011
  5. @xaviershay
Commits on Jan 19, 2011
  1. @snusnu
Commits on Jan 18, 2011
  1. @snusnu
Commits on Jan 17, 2011
  1. @jpr5

    Make Property lookups defensive against same-named custom properties.

    Background: Property class lookups are triggered through const_missing,
    typically when defining a property in the Model DSL and referring to it by
    innermost class name (e.g. "Serial").  This in turn maps to Property#find_class,
    which uses an algorithm that effectively relegates lookups inside the
    descendants tree to a flat namespace of demodulized names.  The algorithm
    returns the most-recently-defined property of the same name, which is incorrect
    in the case where a custom property with the same class name as a DM built-in is
    present, but not relevant in all contexts. (FYI this problem was present before
    the demodulized_names optimization was introduced.)
    
    We solve this problem by only ever adding to the lookup table (not allowing
    overrides).  Given that DM typically gets its property classes loaded first,
    this means its types are always "reserved", and anything externally-derived will
    be included for indirect lookups only when they don't override built-in type
    names.  For the common case, this should be fine.
    
    For external property authors who want to provide "replacements" for builtins
    (e.g. in a non-DM-supported adapter), they should follow the convention of
    wrapping those (or all) properties in a module, and include'ing the module on
    the model class directly.  This bypasses the const_missing lookup that would
    normally check the Property descendant tree/table, ensuring the correct property
    class mapping in the context of a given model.
    jpr5 committed Jan 17, 2011
  2. @solnic

    Collection should use loaded values when setting up default attributes

    [#1336 state:fixed]
    [#1411 state:fixed]
    solnic committed Jan 17, 2011
Something went wrong with that request. Please try again.