references in favor of how DataMapper does it. Addresses issue: http://github.com/halorgium/dm-salesforce/issues/#issue/6
…t value" behavior DataMapper explicitly disallows :default => nil in class property declarations. When a DataMapper custom Type declares a non-nil default, there is no way to get nil property values "by default" upon object creation - they have to be set explicitly every time. This flies against long-standard DB and DM convention, where declared fields are nullable by default unless explicitly specified otherwise (SQL: NOT NULL, DM: :required => true). This is also true of the Salesforce object model. If default values are desired, they should be expressed via class property declarations, not underlying Type. Maybe validation behavior should be considered separately?
…ctionality of the library.
Properly switch between 1/0 for writes and TRUE/FALSE for WHERE clauses. Support negation operator correctly. (i.e. :id.not => Account.engineyard.id) Refactored using DataObjectsAdapter as a template. More similarities between these modules now.
…l gems are running happily against it. a point release will followin a week or two after we've evaluated it
…red an association spec
… a bunch of unused code, refactored error handling in the adapter
…remove traces of auto_migrate, introduce custom types to ease intercepting BS between the adapter and model layer, test review to think about more than just EY's need.
…d by SF at the same time (i.e. >1 key collision). Also added some NOTE/TODO/FIXMEs for problems observed while debugging a related issue. Still some bugs to track down.