I am using ruby on rails with postgresql database. A weird thing happened that some of the tables_id_seq are not starting from 1, but 980190963. But some of the seq are correctly starting from 1.
The problem is when I tried to insert data into those table which seq not start from 1, unique primary key violation raised occasionally.
--EDIT--
I found that when I do
rake db:migrate test
The problem happens.
If I do
rake db:migrate RAILS_ENV=test
The problem has gone.
If you don't need to keep the data in those tables, you can run the following which will reset the table (THIS WILL REMOVE ANY DATA THERE) and restart the tables id to start at 1. THIS IS ONLY VIABLE IF YOU DON"T NEED THE DATA IN THAT TABLE!
ActiveRecord::Base.connection.execute("TRUNCATE TABLE table_name_here RESTART IDENTITY")
As far as why your tables are starting at that id value I would start by checking your migrations. Maybe somewhere in the code there is an "Alter Sequence" sql statement but again not sure.
Related
I have an issue with my Rails app database which now prevents me from completing any migrations.
I've run the following on my command line with the following results -
PRAGMA table_info(events);
0|id|INTEGER|1||1
1|title|varchar|0||0
2|location|varchar|0||0
3|date|date|0||0
4|time|time|0||0
5|description|text|0||0
6|organised_by|varchar|0||0
7|created_at|datetime|1||0
8|updated_at|datetime|1||0
9|user_id|integer|0||0
10|image_file_name|varchar|0||0
11|image_content_type|varchar|0||0
12|image_file_size|integer|0||0
13|image_updated_at|datetime|0||0
14|category_id|integer|0||0
15|url|varchar|0||0
16|number_of_spaces|integer|0||0
17|price|integer|0||0
18|is_free|boolean|0||0
19|organiser_profile|url|0||0
The issue here is with No 19 on this table -
19|organiser_profile|url|0||0
Url is not an acceptable data type which was inputted in error. I believe this is the stumbling block preventing my database from committing any further migrations.
I'm fairly new to Rails and have never manually amend a database before. What I want to do is the following -
Delete / remove / dump - No 19 from my Events table. The entire
line has to be gone.
Check what is in the database before I perform a rake db:drop (this app is in development so there won't be
much
Before I perform the following action -
bundle exec rake db:drop db:create db:migrate, I want to briefly understand what consequences could come from this
I'm pretty sure this is what is required to fix this issue and allow me to perform migrations again and move forward with my app. I've never done any of the above before and would be extremely grateful for any assistance on this process.
You're not in production yet or in danger of losing valuable information so just check out the db file from github from before the erroneous migration.
git checkout <commit> file
Then fix the migration that's erroneous then run migrations again with rake db:migrate. There's no need in this case to be trying to manually edit the table from the command line, unnecessary.
My database is imported from open street map using a tool Osmosis. Every time I import new data using Osmosis it checks in the table "schema_info" and throws error if "schema_info" is not found.
Now on this same DB I made small modifications using rails migration. After I run rake db:migrate, rake automatically drops the "schema_info" table and replace it with "schema_migration".
Is it possible to tell rake to keep "schema_info" after migration?
You need to create the table in a migration, as you would for any table. Any modification to the database schema should come in the form of a migration, regardless of how minor.
I created an integer for a phone number, and then learned that it is better to consider it as a string due to it's size.
I decided then to change directly the migration and apply db:reset instead of adding a new migration since the project is only on my computer at this moment. Db:reset worked but it doesn't seem that my database changed.
It raised a lot of questions :
Is there a command to analyse a database and identify the types of its columns ?
Does db:reset allow to modify a migration, like after rolling back a migration ?
Even though it isn't preferable, what are the conditions to modify directly a migration ?
The db:reset task resets the database by dropping the database and then loading schema.rb - it does not run migrations again. If you dropped the database, then created it and ran db:migrate then you should get the desired outcome
Change the field as string in migration, then run the commands:-
rake db:drop
rake db:create
rake db:migrate
And it will change the field type from integer to string.
I have 3 different schemas in one Rails application. My preparation of the test database using rake db:test:prepare fails with:
psql:/Users/me/myapp/db/structure.sql:7417: ERROR: relation "schema_migrations" does not exist
LINE 1: INSERT INTO schema_migrations (version) VALUES ('20131213203...
That's because it is not proper setting the Postgres search_path before doing all the insertions to the schema_migrations table. I haven't messed with this code in about 8 months and can't remember what I did. I haven't the faintest idea of how I even got those other schema to dump.
You may want to try rake db:structure:dump and / or rake db:schema:dump and try re-running rake db:test:prepare. The former should create the structure.sql and the later the schema.db
I was able to accomplish what I needed by doing two things:
Overriding the purge task under db:test in AR's railties to call a custom drop_database_objects method.
Using a little-known attribute in my database.yml: schema_search_path: public
The first thing lets me drop only the database objects I want, leaving my other support databases intact.
The second thing just creates the structure from my main database, and doesn't try to create the structure from the other databases. It looks like a bug in that it structure:dump doesn't set the schema search path appropriately at the end of the structure.sql script, right before the inserts into the schema_migrations table in a multi-schema instance. These fixes make that not necessary.
I have a migration that creates a postres sequence for auto incrementing a primary identifier, and then executes a statement for altering the column and specifying the default value:
execute 'CREATE SEQUENCE "ServiceAvailability_ID_seq";'
execute <<-SQL
ALTER TABLE "ServiceAvailability"
ALTER COLUMN "ID" set DEFAULT NEXTVAL('ServiceAvailability_ID_seq');
SQL
If I run db:migrate everything seems to work, in that no errors are returned, however, if I run the rails application I get:
Mnull value in column "ID" violates not-null constraint
I have discovered by executing the sql statement in the migration manually, that this error is because the alter statement isn't working, or isn't being executed.
If I manually execute the following statement:
CREATE SEQUENCE "ServiceAvailability_ID_seq;
I get:
error : ERROR: relation "serviceavailability_id_seq" already exists
Which means the migration successfully created the sequence! However, if I manually run:
ALTER TABLE "ServiceProvider"
ALTER COLUMN "ID" set DEFAULT NEXTVAL('ServiceProvider_ID_seq');
SQL
It runs successfully and creates the default NEXTVAL.
So the question is, why is the migration file creating the sequence with the first execute statement, but not altering the table in the second execute? (Remembering, no errors are output on running db:migrate)
Thank you and apologies for tl:dr
I separated the creation of sequences and the altering of tables into two migrations.
When running:
rake db:migrate
The sequences would not be created nor the tables altered and the rake would run successfully.
If however, I ran the migrations seperately:
rake db:migrate VERSION=1
rake db:migrate VERSION=2
The sequences would be created, and the tables altered as expected.