
Dm-aggregates 0.10.0 doesn't work with postgres
Reported by BrianTheCoder | September 8th, 2009 @ 03:16 PM
When I try doing model.count I get
NoMethodError: undefined method aggregate' for
#<DataMapper::Adapters::PostgresAdapter:0x26f89c8><br/>
from /Users/williamsmith/.gems/gems/dm-aggregates-0.10.0/lib/dm-aggregates/repository.rb:5:in `aggregate'
from /Users/williamsmith/.gems/gems/dm-aggregates-0.10.0/lib/dm-aggregates/aggregate_functions.rb:166:in `aggregate'
from /Users/williamsmith/.gems/gems/dm-aggregates-0.10.0/lib/dm-aggregates/aggregate_functions.rb:38:in `count'
from (irb):1
Comments and changes to this ticket
-
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.
-
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) 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:
- A check to see if the other plugin has been required, and mix into it if it has.
- 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...
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
People watching this ticket
Attachments
Tags
Referenced by
-
1029 Dm-aggregates 0.10.0 doesn't work with postgres [#1029 state:resolved] http://github.com/datamapper/dm-a...