Skip to content
Commits on Jul 28, 2010
  1. @dkubb

    Only track changed values when persisted state is Dirty

    dkubb committed Jul 27, 2010
    [#1355 state:resolved]
  2. @dkubb

    Updated gemspec

    dkubb committed Jul 27, 2010
  3. @dkubb

    Updated Property subclasses to lazily inherit defaults from parent cl…

    dkubb committed Jul 4, 2010
    * Instead of eagerly copying the default options to each subclass, the
      subclasses' accessor will ask the superclass for the value if it has not
      been explicitly set.
      This should not change behaviour of the subclass accessors in the
      normal case. The only extra behaviour this adds is the ability to
      reconfigure a Property and it's subclasses by explicitly setting
      a value in the Property, eg:
        # set all String properties to have a default length of 255
        # set all Boolean properties to not allow nil (force true or false)
        # set all properties to be required by default
        # turn off auto-validation for all properties by default
        # set all mutator methods to be private by default
      Please note that this has no effect when a subclass has explicitly
      defined it's own option. For example, setting the String length to
      255 will not affect the Text property even though it inherits from
      String, because it sets it's own default length to 65535.
Commits on Jul 15, 2010
  1. @dbussink

    Put the Inflector into our own namespace

    dbussink committed Jul 15, 2010
    It's not a sign of being a nice citizen that in case people don't
    use ActiveSupport, they end up with this constant defined anyway.
  2. @dbussink
  3. @dbussink
Commits on Jul 12, 2010
  1. @solnic
Commits on Jul 9, 2010
  1. @solnic

    Minor clean up in dump/load

    solnic committed Jul 9, 2010
  2. @solnic
  3. @solnic

    Moved property shared specs to dm-core/spec.

    solnic committed Jul 9, 2010
    This makes easier to require these shared specs in external
    plugins/projects where you want to check behaviour of your custom
    property types. Just do:
    require 'dm-core/spec/shared/semipublic/property_shared_spec'
    require 'dm-core/spec/shared/public/property_shared_spec'
    describe DataMapper::Property::MyAwesomeFoo do
      before :all do
        @name          = :foo
        @type          = DataMapper::Property::MyAwesomeFoo
        @primitive     = String
        @value         = 'value'
        @other_value   = 'other value'
        @invalid_value = 1
      it_should_behave_like 'A semipublic Property'
      it_should_behave_like 'A public Property'
      # here go your custom examples
Commits on Jul 8, 2010
  1. @snusnu
  2. Append Property::Lookup extensions to Model

    Piotr Solnica committed Jul 8, 2010
  3. Updated HugeInteger property used in specs

    Piotr Solnica committed Jul 8, 2010
  4. @postmodern

    Added DataMapper::Property::Lookup module.

    postmodern committed with Piotr Solnica Jul 7, 2010
    The module provides transparent access to Property and Type classes via
    a const_missing method.
Commits on Jul 7, 2010
  1. @solnic

    Adds Property.determine_class as a part of the semipublic API. This m…

    solnic committed with Piotr Solnica Jun 27, 2010
    is used by and Model.const_missing hook to figure out
    what property class should be used. It covers all the various cases like:
    class User
      include DataMapper::Resource
      # This is a part of DataMapper::Property namespace, const_missing hook
      # will catch it
      property :id,   Serial
      # This doesn't trigger const_missing hook hence we need to map it to
      # DataMapper::Property::String inside method
      property :name, String
      # This might not be defined inside DataMapper::Property namespace and
      # we need to map it to a correct Property-derived class like
      # YourApp::DataMapper::Properties::Hash or whatever else
      property :opts, Hash
      # This might be some deprecated Type that we need to support until
      # DataMapper 1.1. Mapping to a Property class is based on type's
      # primitive. ie if Foo.primitive == String then we create a
      # DataMapper::Property::String instance and set Foo as its type
      property :foo,  Foo
Commits on Jul 5, 2010
  1. @snusnu

    Minor spelling fix

    Rob Tirrell committed with snusnu Jul 5, 2010
    [#1346 state:resolved]
Commits on Jul 3, 2010
  1. @dkubb

    Minor formatting fix

    dkubb committed Jul 3, 2010
Commits on Jun 27, 2010
  1. @snusnu

    Minor documentation fixes

    snusnu committed Jun 27, 2010
Commits on Jun 10, 2010
  1. @namelessjon

    Initialize relationships before checking for keys

    namelessjon committed Jun 10, 2010
    DataMapper.finalize now initializes all relationships before checking
    for keys.  This allows a join model which consists entirely of
    belongs_to relationships with `:key => true' to be considered valid.
    [#1313 state:resolved]
  2. @namelessjon

    Wrap finalize spec cleanup in ensure blocks

    namelessjon committed Jun 10, 2010
    This means one spec failure won't cascade through the specs.  An after
    block might seem to be the solution, but we'd need one per spec, which
    means nested describes for no other reason than to clean up.
  3. @dkubb
Commits on Jun 8, 2010
  1. @dkubb

    Version bump to 1.0.0

    dkubb committed Jun 8, 2010
Commits on Jun 6, 2010
  1. @dkubb
  2. @dkubb

    Test to make sure the model has a name when finalizing it

    dkubb committed Jun 5, 2010
    [#1303 state:resolved]
  3. @dkubb
  4. @dkubb

    Changed spec description strings to use single quotes

    dkubb committed Jun 5, 2010
    * My general coding style is to only use double quotes when I am doing
      string interpolation somewhere in the string, and otherwise defaulting
      to using single quotes at all times. When I see single quotes I don't
      have to visually inspect the String to see if anything else is going
      on inside it to alter it at runtime.
  5. @dkubb

    Spec error message for own exceptions

    dkubb committed Jun 5, 2010
    * In general I believe if your code raises an exception you should spec
      the error message that you return. Not only will this make the code
      pass when heckled, but it also alerts you to unintended changes in
      the messages.
      For the record, I do not believe in speccing exceptions raised by ruby
      or code that is not under test.
  6. @dkubb
  7. @dkubb

    Fixed incorrect spec name

    dkubb committed Jun 5, 2010
  8. @dkubb

    Minor whitespace formatting fix

    dkubb committed Jun 5, 2010
Commits on May 29, 2010
  1. @dkubb

    Fixed bug with hooks applied to subclasses

    dkubb committed May 28, 2010
    * Improved specs for resource hooks
    * Added specs for inherited after hooks
    * Changed inherited hooks to be based on instance method
    [#1271 state:resolved]
  2. @dkubb

    Ensure the SaveFailureError exception has a reference to the resource

    dkubb committed May 28, 2010
    * When dm-validations is being used, this allows the exact errors to be
      retrieved from the invalid resource when the SaveFailureError exception
      is raised.
  3. @dkubb

    Refactored resource destruction

    dkubb committed May 28, 2010
  4. @dkubb
  5. @dkubb
Something went wrong with that request. Please try again.