Datamapper DataMapper

Comments and changes to this ticket

• You flagged this item as spam.
  

  deepfryed September 21st, 2009 @ 01:58 AM

  • Assigned user set to “Dan Kubb (dkubb)”

  i was racking my brain for 15mins, too bad this got through -- the attached patch fixes the bug. The dm-adapters.rb code does not include the adapters module for aggregates thats all.

  • dm-aggregates.patch 266 Bytes
• 

  Dan Kubb (dkubb) September 22nd, 2009 @ 12:15 PM

  • State changed from “new” to “unconfirmed”

  @deepfryed: thanks for looking into this, unfortunately this patch won't work in all cases.

  The DataMapper::Adapters::DataObjectsAdapter namespace isn't loaded into memory until the DataMapper.setup is called, which should happen after everything has been required.

  Since this defines the class DataObjectsAdapter, without specifying that it inherits from AbstractAdapter, it will probably throw some exceptions saying there's a class mismatch.

  There's a new callback mechanism in DM 0.10, where a const_added hook inside the DM::Adapters namespace will mix-in new behavior into adapters that are loaded. This is used within dm-core to mix-in migration and transaction behavior. It also allows you to define behavior on a per-adapter basis lazily, so the adapter namespace doesn't have to be set up beforehand.

• 

  Dan Kubb (dkubb) October 8th, 2009 @ 01:56 AM

  • State changed from “unconfirmed” to “confirmed”

  Brian said that he resolved this problem by making sure rails_datamapper is included last in the list of DM related gems.

  I am not closing this ticket yet, until we can make sure this gem require order is fixed properly.

• 

  Dan Kubb (dkubb) February 2nd, 2010 @ 02:34 AM

  • Assigned user cleared.

  [bulk edit]

• 

  Dan Kubb (dkubb) May 23rd, 2010 @ 09:50 PM

  • State changed from “confirmed” to “accepted”
  • Assigned user set to “Dan Kubb (dkubb)”

  We have a solution to this problem and have implemented it in dm-constraints, dm-migrations and dm-transactions.

  Basically it requires two pieces of code:

  1. A check to see if the other plugin has been required, and mix into it if it has.
  2. A system where if the other plugin is not required that you can register with and have the mix-in applied when the plugin is required.

  This is actually surprisingly simple once we found the right pattern. In the future this will probably be generalized into something more reusable, but for now we'll be applying the same solution in those plugins to dm-aggregates. The end result is that require order will no longer affect how stuff is mixed in.

• 

  Dan Kubb (dkubb) May 24th, 2010 @ 01:04 AM

  • State changed from “accepted” to “resolved”

  (from [cb99adc2a15eae2751eddaa648583c314eb06312]) Ensure load order does not change aggregate behavior

  • Use same approach as dm-constraints, dm-transactions and dm-migrations

  [#1029 state:resolved] http://github.com/datamapper/dm-aggregates/commit/cb99adc2a15eae275...