-
Notifications
You must be signed in to change notification settings - Fork 191
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
explicit cast error on postgres 9.3 (Ubuntu 14.04) #70
Comments
Something's messed up in your setup. The queue column is text, not int. On Monday, January 5, 2015, Solomon S. notifications@github.com wrote:
|
I have the environment variable QUE_QUEUE= default so that it picks up the active job queue. Other than moving to a newer version of the postgres server nothing has changed. Any thing in particular I should investigate? |
I'm not sure what would cause this - can you put together a self-contained example for us to use to reproduce? Was the Postgres upgrade to 9.4? I haven't tested Que with it yet, but I don't recall anything in the changelog that would affect this? |
Ah, I see in the issue title that it's PG 9.3, never mind about that part. |
I wiped out the table, undid the change I made to the local gem, and reran the migration, now this is the error:
postgres version is 9.3+154 |
Looks like reverting the local gem didn't stick, I fixed that and now it is working. It seems that que uses the DATABASE_URL and not database.yml for connection? This was causing it to not see the correct database as I use inheritance in my database.yml and specify different databases per enviroment. Is this the intended behavior and is this documented (I might have just missed it) |
Que uses DATABASE_URL in the specs, but in actual use it piggybacks on If you want it to connect to a different database than whatever
On Tue, Jan 6, 2015 at 11:33 AM, Solomon S. notifications@github.com
|
Here is my database.yml, I specify the database_url via enviroment variable, then switch out the database per enviroment and user running the instance. I was includeing everything BUT the database in the DATABASE_URL (since I was specifying it later) but when I added it to the DATABASE_URL que started working. Note that evertyhing else worked as expected with the first setup. I know this is an edge case, but does not seem to violate any rails guidelines.
I have resolved this as I documented above, however I do not know if this warrants any further investigation. Close this issue if you think this was a one off problem. |
Sorry, I'm confused by what exactly you changed to make it work. The error you are having indicates that something it sending the "queue" argument to PostgreSQL as an integer, not a string. If that can be reproduced by an incorrect database.yml, that sounds like a bug that should be fixed. |
I would modify DATABASE_URL with URI.parse to switch databases, that should allow you to cleanly modify the database part of the URL. I still think there might be some other bug happening in que that would cause this. |
Que doesn't do anything with database.yml - it just assumes that ActiveRecord has working connections and borrows them as needed. I guess it's possible that, if you're waiting until some time after startup to give ActiveRecord a database name and therefore establish a connection (I didn't know that ActiveRecord had that functionality?) and Que's worker pool starts up before ActiveRecord is ready, that would cause problems. But it's probably a bad idea to use ActiveRecord like that in most cases in the first place, so if you're able to define the database name in database.yml that's probably what you should do. As for the queue column being created with the integer datatype - I'm not sure what would cause that if you hadn't already hacked Que or manually modified the table in PG. Since it's never come up before and you're not able to reproduce it now, I don't think there's a lot we can do to investigate it, so I'm going to close this for now. But if it happens again to you or anyone else, or (better yet) if anyone is able to make a self-contained reproduction of how to cause it, I'll gladly look into it. |
Yeah, if you see this again, it would be nice to get the output of the following command from psql. Looks like something happened to convert the queue column to an int in your system.
|
I seem to be getting this same issue on PostgreSQL 9.4.1 using Postgres.app - though I only get this when running my test suite, my development database stays intact.
Not entirely sure what's causing it, but whenever I run my test suite it re-converts the column to int4 from text (after manually changing it to text)
The only way I have been able to fix the problem is by dropping my test database and re-migrating. |
Something has redefined your queue column as an integer, set up a sequence for it, and declared it the primary key. I suspect Rails/ActiveRecord, since the run_at default has also been changed to a static value instead of now(). Have you used the Rails rake tasks for loading the schema, maybe? |
My test suite utilises a MySQL and a PG database. This is the only possibly cause I can think of, reading up I see it utilises available AR connections. Here's a look into my rails_helper file for database cleaner incase this could effect
In my test that causes the issue, I do load in seeds to the MySQL db in a before block This would cause AR to connect to MySQL and create records. |
And you're trying to have the same schema across Postgres and MySQL? Anyways, I expect this is a byproduct of not setting schema_format to :sql, like we suggest doing in the README? |
error when running 'rake que:work'
I was able to resolve this be making the following change in /lib/que/sql.rb (line 10)
to
The text was updated successfully, but these errors were encountered: