* This extra behavior is probably unecessary and would be little used. In addition it would cause "0123" to be treated as 83 rather than 123, which I think is probably more expected to anyone familiar with how String#to_i works. It's only really the Kernel::Integer() method that treats "0123" as an octal, and it's in far less frequent use than String#to_i. If specific octal, binary or hex coercion is necessary then I would probably suggest using a custom type rather than an Integer property. I am removing this for now, since if I'm wrong it will be easy to add back in, but it would be really difficult to remove behavior like this after a release.
…rrides in other repositories
* Updated docs for 1:m and m:m CRUD methods
* Use String#<< instead of String#+ where possible since it doesn't create a new String instance.
* Moved logic from DataMapper.setup to DataMapper::Adapters, and split up the work across smaller, single purpose methods.
* Created Relationship#valid? to test a Resource to see if it would be a valid target resource * Created Property#valid? to test a value to see if it matches the constraints for the Property
* Pushed foreign key mapping into the adapter so that it can handle more of the logic itself. This allows adapters to storage engines that do not link relationships using the PK/FK concept used by RDBMS'. * Allows for the possible use of subqueries in engines that support it, since if we pass in a Collection, we should be able to use it's Query object to construct a subquery.
…ty if available
* Work should be performed by "unsafe" method, while the "safe" methods are used by hooks. * Changed Resource#_update to simply be available for hooks, and delegates to Resource#update!
* Some queries were being sent to the adapter when they would not return *any* results because they were invalid (like specifying that the value must match one entry in an empty list). * Added AbstractCondition#valid? and AbstractOperation#valid?
…for the join relationship
* This represents a change in how we typecast values. If the value does not match a format we know can be coerced into the object, then we skip typecasting and leave the value as-is. If dm-validations is enabled, the value can be identified as invalid, but the original value is left alone by dm-core rather than turned into a nil.