undefined method `group_by_products_id' error in heroku

[gutenye]

when I visit /admin/products in heroku, I got

2012-03-09T07:08:05+00:00 app[web.1]:                                          
2012-03-09T07:08:05+00:00 app[web.1]:                                          
2012-03-09T07:08:05+00:00 app[web.1]: Started GET "/admin/products" for 1.1.1.1 at 2012-03-09 07:08:05 +0000
2012-03-09T07:08:05+00:00 app[web.1]:                                          
2012-03-09T07:08:05+00:00 app[web.1]: NoMethodError (undefined method `group_by_products_id' for []:ActiveRecord::Relation):
2012-03-09T07:08:05+00:00 app[web.1]:                                          
2012-03-09T07:08:05+00:00 app[web.1]:                                          
2012-03-09T07:08:05+00:00 app[web.1]:                                          
2012-03-09T07:08:05+00:00 app[web.1]: cache: [GET /admin/products] miss        
2012-03-09T07:08:05+00:00 app[web.1]:   Processing by Spree::Admin::ProductsController#index as HTML
2012-03-09T07:08:05+00:00 app[web.1]: Completed 500 Internal Server Error in 13ms
2012-03-09T07:08:05+00:00 heroku[router]: GET foo.herokuapp.com/admin/products dyno=web.1 queue=0 wait=0ms service=20ms status=500 bytes=728

but every works well in development.

Environemnt

heroku: cedar stack. postgresql database.
development: ruby 1.9.3, spree 1.0.1, rails 3.1.4, postgresql 9.1.3

How I deploy to heroku

$ git push heroku master
$ heroku run rake db:migrate
$ heroku run db:admin:create

[gutenye]

heroku restart or database reset will fix it

[radar]

@boxfirepress Going to need more information. Please see the contributing guide.

[radar]

Please don't expect help if you're going to be passive aggressive with us.

I need to know the version AT LEAST so I can be sure that this is really an identical issue.

On 20/02/2013, at 9:13, S S S notifications@github.com wrote:

What part of same problem was difficult to understand?

In any event, I fixed it by removing the corrupted sample data from the installer.

—
Reply to this email directly or view it on GitHub.

[radar]

I'm sorry, but the Spree team won't help somebody with such an aggressive attitude. Such an attitude is not welcome here. If you think I am being aggressive now, you are mistaken. I am being firm.

I linked you to the contributing guide, like I link people to it almost every day, so that I didn't have to repeat myself. This is why the contributing guide exists: to provide a useful way of informing users how to provide bug reports that are useful for us.

Simply stating a year after an initial bug report that you have the EXACT same issue is showing a complete disregard for the guidelines which expressly state we need to know the version of spree you're running. There have been several spree releases since which MAY have fixed this issue. We can't retroactively fix gem releases for Spree, so we NEED to know the version of Spree you're running to know that this is a current and relevant problem.

Please drop the attitude. It is not conducive to me wanting to help you.

On 20/02/2013, at 9:56, S S S notifications@github.com wrote:

Really? It's obviously the same issue.

I'm being openly agressive and I was only reflecting only reflecting your rudeness. Had there been a material difference in the setup, I would've made it a point to tell you since I posted more information in the stack trace than the last person did (yet he still managed to get a reply that wasn't: you didn't follow the arbitrary rules in some guide so no help for you.)

Could you not have just asked for what you wanted? You could've. It's a moot point anyway. I don't need your help. The code has a bug, though and the solutions posted won't fix it.

—
Reply to this email directly or view it on GitHub.

[radar]

With still no Spree version, you cannot realistically expect us to solve this problem. You're being extremely unreasonable and still aggressive. Please stop this.

[radar]

@boxfirepress This is not the first time I've asked you to chill out, btw: thoughtbot/paperclip#687 (comment)

[hhill]

Wow, I came across this searching google for the error. Top result. Makes me wonder if I should be recommending this to a client (also had an issue jirafe that just automatically resolved itself, not sure why).

Anyway, I can confirm this seems to happen with an empty products table in 1.3.2 on heroku with rails 3.2.11 and the posted solutions don't fix it (not sure why they would, though). I have a full stack if you want to see it. It will fix when the first product is created, which has to be done by manually navigating to the route for a new product because from what I can see there's no other accessible link than on product#index.

@boxfirepress, I feel your frustation, but more information is always better. Should an open source developer try their best to help you with out calling you passive agressive or whatever else, yes. But you reap what you sow and since your posts are gone, I can't exactly see what you were saying back. I imagine it wasn't nice.

@radar would you rather make a point or fix the bugs? Looking through the numerous issue requests here I see others have provided far less information and gotten more nicely crafted replies, whether asking for more information or trying to diagnose the problem. As for the paperclip thread--which you didn't need to bring up, that's a little douchey--he and the others were right. The docs were wrong and providing the wrong instructions. He was upset because no one was listening to him until a third person got involved and fixed them. Why did you even insert yourself? I remember it very clearly because A LOT of people were having the exact same problem at that time on SO. The docs were simply wrong.

But the point is, who cares -- let's just fix this. Do you need any other information on the error?

[hhill]

I should add, also, I think this is a PostgreSQL problem. The same did not happen in development, but I was using Sqlite at that point. I didn't do anything in development other than a quick start of the server to check. It might be specific to that DB.

[radar]

@hhill: Honestly, I would rather do both. I ask that people respect the work that we put into the system and not act like arrogant douchebags. We are under an extraordinary amount of pressure to ensure things are right. We cop all the blame for when things aren't, and surely you can imagine how that makes us feel?

The paperclip thread was brought up as a great example that @boxfirepress has offended before and has not learned his lesson. Yes, it was douchey. Fire with fire. Docs for the master branch should not be used as a reference for a current gem release anyway. We have a GIANT BIG DISCLAIMER at the top of our master branch's README for this same reason.

I inserted myself because I wanted to help the Paperclip guys. I would expect anybody else to do the same for us on Spree if we were being attacked in the same way. The over-the-top arrogant and aggressive response by @boxfirepress (and co.) was not warranted at all. Paperclip is provided on an "as-is" basis, so there is no guarantee that the software should work at all, ever. It wouldn't be fair at this point if I didn't point out Spree has the same clause, so there you go.

That kind of attitude displayed by @boxfirepress and other, similar people in the OSS community doesn't make people feel like wanting to help you at all. In fact, it does the opposite. It's what drives people away from even wanting to provide open source software in the first place. You wonder why we are hard-assed arrogant bastards? Because we have to deal with shit like this at an extremely common rate. I have a zero tolerance for this attitude.

Defending @boxfirepress is folly. He is in the wrong. He must correct his behaviour, because it is toxic, reeks of entitlement and is hate-filled.

Sigh.

---

I agree that this does indeed look like a PostgreSQL problem. The scope is defined like this:

    if (ActiveRecord::Base.connection.adapter_name == 'PostgreSQL')
      if table_exists?
        scope :group_by_products_id, { :group => column_names.map { |col_name| "#{table_name}.#{col_name}"} }
      end
    else
      scope :group_by_products_id, { :group => "#{self.quoted_table_name}.id" }
    end
    search_scopes << :group_by_products_id

So... could the problem be with that table_exists? check? Does the spree_products table exist when this file is being loaded in the first place on Heroku? If not, I suspect that is the problem. Strangely, our tests are not showing this issue happening on our CI server. A patch to fix this issue with some tests would be extreeeemely appreciated.

Thank you for reading all of that.

[iloveitaly]

@radar and the rest of the spree team: thank you for all the work you put into making this software great. I, and I think the majority of the people using Spree in production, realize the hard work and thought that has been put into the software. Yes, there are problems, but those problems don't compare to the disadvantages of using another eCommerce system that is impossible to customize and hard to upgrade.

[hhill]

Your choice to make. We'll disagree on the Thoughtbot issue — if the very first response had listened to what was being reported it probably wouldn't have devolved the way it did. I didn't see an attack, I saw a bunch of people just not listening to each other. The same here. You could've made the point and helped at the same time, right? And it maybe wouldn't have devolved again. I've been the one not listened to too many times to write anyone off. But it's over, onward.

I'll do some more testing to see what if I can pinpoint exactly what is happening. I honestly don't know enough about how Spree gets setup in the initial deploy to know what tables are there or aren't. BUT, I did load the sample data and had the issue the first time, so I dropped and recreated the database without the sample and the issue didn't resolve. I then manually navigated to the create path and made a product, and it worked. It doesn't make since why the empty table and the table with the sample data would have the same problem.

[radar]

I can't help because I don't know how the problem is caused and I don't have time to investigate it right now. This is why I want to enlist other people to help out.

[hhill]

Well, for anyone else looking at this, this might be a possible related issue -- not sure what happened with it:

dad81d6

[radar]

I just quickly generated an app using PostgreSQL as the DB with Spree 1.3.2, no products loaded in the products table and going to /admin/products works fine.

[radar]

I was also unable to reproduce this issue by running rake db:reset, with this line in db/seeds.rb:

p Spree::Product.scoped.group_by_products_id

[radar]

However, on Heroku I have now been able to reproduce this issue.

[radar]

I've got a definite fix for this problem now on my repo (radar/spree), in the 1-2-stable, 1-3-stable and master branches there. Please confirm that this fixes the problem for you too. I will be merging it soon.

So much for not having time to do it, hey?

[hhill]

That was super fast. I'll check it out.

[hhill]

Okay, I just deployed to Heroku and the fix appears to work.

[radar]

Great! Thanks Hans!

On 20/02/2013, at 12:47, Hans P notifications@github.com wrote:

Okay, I just deployed to Heroku and the fix appears to work.

—
Reply to this email directly or view it on GitHub.

[schof]

@radar I didn't see that anyone was being overly aggressive in this particular thread (were those comments deleted?)

Best solution for someone trolling is to politely ignore them and to only respond to people in the thread that are acting reasonably. In any event, it sounds like we were able to turn things into a productive conversation and resolve the issue.

[radar]

Yes those comments were deleted. You can see his replies by clicking on the
little "..." underneath my email responses.

On Wed, Feb 20, 2013 at 2:34 PM, Sean Schofield notifications@github.comwrote:

@radar https://github.com/radar I didn't see that anyone was being
overly aggressive in this particular thread (were those comments deleted?)

Best solution for someone trolling is to politely ignore them and to only
respond to people in the thread that are acting reasonably. In any event,
it sounds like we were able to turn things into a productive conversation
and resolve the issue.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1247#issuecomment-13814108.