Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When versions table joins another table with created_at, version.next & version.previous raises AmbiguousColumn error #295

Closed
hangsu opened this issue Nov 11, 2013 · 2 comments
Assignees
Milestone

Comments

@hangsu
Copy link

hangsu commented Nov 11, 2013

The title says it all!

I have a default scope like this:

default_scope { joins('INNER JOIN foobars ON foobars.id = versions.item_id') }

calling version.next gives me:

PG::AmbiguousColumn: ERROR:  column reference "created_at" is ambiguous
LINE 1: ...e" = 'Foobar' AND "versions"."item_id" = 13808 AND (created_at...
                                                             ^
: SELECT  "versions".* FROM "versions" INNER JOIN foobars ON foobars.id = versions.item_id WHERE "versions"."item_type" = 'Foobar' AND "versions"."item_id" = 13808 AND (created_at > '2013-11-04 22:07:37.808161')  ORDER BY created_at ASC LIMIT 1

The foobars table also has a created_at column that's colliding with the version created_at.

Using paper_trail sort of negates the necessity of a created_at column in my foobars table, but thought I'd report my findings anyhow.

@ghost ghost assigned batter Nov 12, 2013
@batter
Copy link
Collaborator

batter commented Nov 12, 2013

@kevinsu22 - Good to know. I think I have a fairly straightforward fix, explicitly declaring the table name in these scopes should alleviate the problem. That being said I'm trying to create a failing test for this to rectify. Where do you have this default_scope declared? Is this on your PaperTrail initializer within the PaperTrail::Version class?

Looks like I can reproduce it that way but am having trouble adding some sort of custom scope method using the joins operative that allows me to reproduce a similar error. I'll keep playing with it and see if I can figure something out unless you have a good idea on how to provide a failing test or spec.

@hangsu
Copy link
Author

hangsu commented Nov 13, 2013

@batter - I have it declared in the initializer. Any difference between having this sort of stuff in the initializer vs the class? (Other than having to restart my server every time i change something)

Here's an example of a custom scope:

scope :custom_scope, -> { joins('INNER JOIN foobars ON foobars.id = versions.item_id') }

(I'm on rails 4)

Perhaps something like

Widget.custom_scope.first.versions.first.next.must_be_silent

This is incredibly poor code, but perhaps it gives you an idea?

@batter batter closed this as completed in 0258fd5 Nov 15, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants