Hi does anyone know what this means? I only get this error when I app is deployed on a server and using PostgresQL. When I'm running locally and testing on SQLite, it is fine. I have a features_simulations join table, I think it is related to it somehow.
Processing AdminController#confirmed (for 211.30.107.155 at 2009-03-25 09:06:21) [GET]
Session ID: 59d7fdbbb6ec77367c310df0c0928a2a
ActiveRecord::StatementInvalid (PGError: ERROR: relation "features_simulations_id_seq" does not exist
: SELECT currval('features_simulations_id_seq')):
/usr/local/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/connection_adapters/abstract_adapter.rb:188:in `log'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/connection_adapters/postgresql_adapter.rb:503:in `execute'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/connection_adapters/postgresql_adapter.rb:1000:in `select_raw'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/connection_adapters/postgresql_adapter.rb:987:in `select'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/connection_adapters/abstract/database_statements.rb:7:in `select_all_without_query_cache'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-2.2.2/lib/active_record/connection_adapters/abstract/query_cache.rb:60:in `select_all'
ActiveRecord doesn't really use compound keys. The joining tables still have to have an ID in them for atomic deletes and updates. I think everyone else has said the same thing but in a more roundabout way.
I'm not sure, but maybe you need id in features_simulations table. Id isn't needed if you use has_and_belongs_to_many relations. But I think for has_many :through, you need id column in your join table.
Try adding it in migration:
add_column :features_simulations, :id, :integer, :primary_key
I think "features _simulations _id _seq" is a sequence that has to be created in the database.
This sequence seems to be generating the id for the table.
In Postgres you can use a serial type for an auto-incrementing field, which will automatically create the necessary sequence. You can use an integer type and manually create the sequence if you want, setting a default as the next value from the sequence.
Seems like the code is trying to find the current value of the sequence and failing because the sequence doesn't exist. I'm not sure if rails automatically creates the right type for Postgres primary keys.
Its a problem with the fixtures. Check your Fixture names against your table names. You will get this error if there is a mismatch between the two.
Related
I have 3 models: movies, movie_tags and movie_tag_counts
It is a classic has many through relationship. My use case is that every movie can have multiple tags and user can vote on tags that were already added.
My Problem is that I can't seem to update an existing object in movie_tag_counts
movie_tag_count = MovieTagCount.first
movie_tag_count.count += 1
movie_tag_count.save
the result is this error message
TypeError: nil is not a symbol nor a string
My best guess is that the reason is that movie_tag_counts table doesn't have an id column of its own, but I still have no idea how to fix it.
My current workaround is to execute a sql statement directly
Turns out my guess was right, ActiveRecord expects an id column, I added it like this
add_column :movie_tag_counts, :id, :primary_key
and everything worked perfectly. I'm sure there's a way to do it without the id column by overwriting some AR methods, but I guess having another column won't hurt that much
I'm working on porting a very large Rails project from DataMapper to ActiveRecord. Among the models that has to be ported is a set of User models that used Single Table Inheritance (STI) to distinguish one type from another. Here is a simplified version of what it looks like:
class User < ActiveRecord::Base
...
end
class AdminUser < User
...
end
Generally, the 'type' field is used to tell the difference between Users and AdminUsers, by storing the class name of the object being saved (i.e. 'AdminUser'). And it works fine in development, but when I try User.create in the test environment, I get:
ActiveRecord::StatementInvalid: Mysql::Error: Column 'type' cannot be null
ActiveRecord tries to insert a new row, setting the type column to NULL... what could cause this to be happening in the test environment, but not in development?
Turns out it was a slight difference in the database table itself that was causing a change in behavior for ActiveRecord. The test database had no default value for the type column, whereas in development, the default value was 'User'. Apparently ActiveRecord uses the default value when inserting data for an object of the primary class type (the class that inherits from ActiveRecord::Base - in this case, User). Why it doesn't just use the class name is beyond my understanding!
My real confusion came when I updated my dev database to have a default for the type column, which I actually knew it needed, because somehow the production database already had one, so clearly my dev database was just out of sync. So I did this:
mysql> ALTER TABLE users MODIFY COLUMN type varchar(50) NOT NULL DEFAULT 'User';
...[ok]
mysql> exit
Bye
$> bundle exec rake db:test:prepare # <-- My Mistake
...[ok]
I thought this was all I had to do, but it turns out running db:test:prepare just matches your test database to your schema.rb file, and my schema.rb file hadn't been updated, so then User.create worked in development, but broke in testing :D
Eventually, I came to understand all of the above, in addition to the fact that I needed to run db:migrate in order to update my schema.rb file BEFORE running db:test:prepare. Once I did that: voila! User.create actually used the default value of the type column to insert new User objects.
Moral of the story:
NEVER let your development database get out of sync with production. If it is: blow it away with a db:schema:load and start over with new dev data! (Or get a production dump or something)
Choose your ORM wisely. R.I.P. DataMapper - I'll miss your elegant abstractions... but not your bugs.
I'm using Mongoid 4.0.0 with Rails 4. My models map tables in another application, and I have no control over the field names.
One of the models has a field named id, which is getting coerced into Mongo's _id field. For example, when I insert a document with an id value of "something" I get
{_id:"something", id:null}
instead of
{_id:ObjectId("<hexstring>"),id:"something"}
Is there any way to avoid this coercion, make Mongoid not conflate the two fields, and leave my id field alone?
As I said, renaming the id field is not an option.
Thanks!
[edited]
This is definitely not a MongoDB issue. It must be in Moped or (my guess) Mongoid.
I've tried changing the params key from :id to :_rid but this is still happening. I'm going to check out aliases, but from my first pass I don't think they're going to help -- they appear to go the wrong way.
This appears to be hardcoded into Moingoid and a pervasive assumption throughout. It's annoying enough, though, that I might come up with a patch to allow users to override the key field on a per-model basis.
Oh well.
I'm currently looking at migrating an existing system (written in spaghetti PHP) over to rails. The problem is, it has to run off of a live database. A lot of the ID columns on these different tables aren't named id. For instance, the customers table has an ID column called Customer_ID. Upon looking, I just realised that rails does infact seem to find by the primary key instead of a specific column called id.
Will I face a lot of problems later with the naming of these ID columns, specifically in stuff like relationships?
After v2.3.8, set_primary_key :col_name is deprecated.
self.primary_key = 'col_name' is recommended.
http://api.rubyonrails.org/classes/ActiveRecord/AttributeMethods/PrimaryKey/ClassMethods.html
Change primary key attribute in model by using
set_primary_key :col_name
I'm trying to create a model with something like:
jobs title:string companyid:uuid
However, when I run db:create, it creates the table with the "title" column but just ignores the "companyid" column. The app of course crashes because ActiveRecord can't find the companyid column. If I add the DB column in manually, the app works (so I know RoR knows how to handle this data type)..
I'd like my DB provisioning and migration scripts to run correctly. I'm using PostgreSQL 9.0 and the postgres-pg adapter.
Anything special I need to do? Thanks!
This should help:
Ruby on Rails: UUID as your ActiveRecord primary key
Your migration isn't working because UUID isn't a supported type. If you look at the link you will see that they used UUID as a column name and string as the type. They also disabled the id column and set their UUID:string column to be the primary key.
There is also the simplified type in the Postgres Adapter that may be helpful for insight to why it works once you create the column manually. Though it just maps UUID to a string.
Fixing migrations so they could handle Postgres UUIDs could be some nice low hanging fruit for a contribution if someone having this issue wanted to contribute to Rails but given that Postgres UUIDs don't really appear to do much and your app will have to generate the IDs they might as well just be strings.