I'm using Sequel::Model. My model has a set_schema block and a create_table call, so the database is completely managed by the model. The database is sqlite.
I'm trying to add columns to the database and I can't find a way to. Adding fields to the schema has no effect. Adding a migration or an alter_table call doesn't do anything. I've asked on IRC and read the docs. I can't find an example of anyone doing this, but it seems simple.
How do I add a column/field to a Sequel Model?
I did a bunch of research and talked to Jeremy Evans. I was going about this wrong. The right way to do this was to remove my schema plugin code and create_table block and move to using migrations. The steps I went through were:
Remove the schema code (create_table, set_schema) from my modesl
Dump the schema from my current sqlite data files into initial migrations into migration files via the sequel -d command
Create a new migration that adds the columns I need via add_column calls in an alter_table block in a change block
Apply the migrations via the sequel -m command
Create rake tasks to run the migrations and hook those tasks into my deploy tasks
Related
I have created psql table through psql console. I have created a model in rails for the corresponding table. Now if I want to write a migration to create a table so that someone using my code doesn't need to create a table through psq console, and also it should not remove table for me when running the migration. How to solve this.
In your migration file:
create_table :foo do
.....
end unless table_exists? :foo
ActiveRecord::ConnectionAdapters::SchemaStatements#table_exists?.
In case you are reading this answer, and you are on Rails 6, a new flag was added to #create_table in Rails 6 beta1 to address this exact problem.
Example:
create_table :posts, if_not_exists: true do |t|
t.string :title
end
Rails encourages developers to modify their database only through migration files. Because when you do manual changes, schema.rb is not updated. This will make other developers schema inconsistent with yours.
If you have created a table in your local database manually, you can drop the table manually and create a new migration file. Then if you run the migration file, it will create the table and update schema.rb accordingly.
If you still want to write the migration only for the other developers, you can create a migration with the create table and then comment it while running the migration. schema.rb will now be updated with the new table because Rails automatically tries to sync your database with the schema.rb file everytime you run a DB command. Now, uncomment the migration change and push your changes for other developers to get the table.
I had an existing table named boss_name and I would like to create a rails model for it.
I used "rails generate bossname" to created the model and added the
self.table_name = "boss_name"
inside the class.
After the model had been successfully generated, I tried to start up rails console and trying to query the table.
Bossname.first give me the first value from boss_name table without problem.
rails console worked fine but when I'm running rspec for bossname_spec.rb, I had error which say "Bossname(Table doesn't exist)".
I hope anyone can tell me why it work for rails console and doesn't work for the application. Any hint on how to make it work on the application too is really appreciated.
That indicates that the boss_name table exists in your development database, but not in your test database. You can copy your current development database schema into your test database like this:
rake db:schema:dump
RAILS_ENV=test rake db:setup
I am just starting my first ruby project. I followed tutorial and built a blog. I thought next i would add a commenting system to extend the project, I just added has_many :comments to my post model. In the tutorial after we built the model we raked the database. Im not entirely sure what it does, but it seems fairly important. Is this something at I will need to do again and any time i update a model? I am using the gem 'sqlite3'
thanks
Every time you create a new model (database table) you got to run the migration, which creates the table in the database. Whenever you make any change to the db, you got to run migrations so as to make sure your db is in sync with your latest changes.
Everytime, you create/edit a model(database table) in rails, you should write a migration for the same. The migration will make the necessary changes to your database once it is run using "rake db:migrate" command.
With the has_many :comments in your blog model. You will need to add a migration to create the comments table, with blog_id as the foreign key, assuming your blog model is called 'blog'.
I have played with Entity Framework 4.3 migrations for some time now, but I have trouble achieving the next behavior: In case my code runs on an existing database, I want the database to be migrated automatically to the latest version, but in case the database doesn't exist, the database should be created automatically from the migrations.
I think the problems is related to the first migration that you create. If you create the first migration using -IgnoreChanges parameter (or manually delete them as explained here: http://thedatafarm.com/blog/data-access/using-ef-migrations-with-an-existing-database/), you will not be able to use migrations in order to create a new table using the DbMigrator class. because you don't have the initial migration. If you create the first migration without using -IgnoreChanges, than the migration of the existing database will not be possible. Does anybody has any solution for this problem?
So you have existing database and you want to use migrations on that database and in the same time you want to support database creation by migrations in case of new deployment?
It looks like little bit unsupported use case. The simplest in this case (not tested) would be either conditional compilation or conditional migration driven by some AppSettings key. It means creating initial migration as if you don't have the database and modify Up method to:
public override void Up() {
if (ConfigurationManager.AppSettings["NewDatabaseRequired"] == "true") {
// Here is generated content
}
}
or
public override void Up() {
#if NewDatabaseRequired
// Here is generated content
#endif
}
There is plenty of other more complicated options including scripting your current database, modify the script to end if tables already exist, add a script as a resource to your migration assembly and execute the script in the Up method generated with -IgnoreChanges.
As another option you can open additional database connection and check if tables from migration already exists (by querying sys.tables view in SQL Server). This will not need generated script.
Suppose I have a database containing 3 tables in a grails application:
User
Activity
Friend
User table table has one to many relation to Activity and Friend tables so in User table I have:
static hasMany = [activies: Activity, friends: Friend]
and in Friend and Activity I have:
static belongsTo User.
Application is deployed and lets says thousands of customers have registered. Now changes are made in the database: Table Activity is dropped. A table Journal is created which is on the many sides of the User table. The User table has a new column added and this column cannot be null. An old column in Friend table is deleted that was also defined as not null.
So given above scenario and assume using MySQL what needs to be done to make above changes without deleting existing customers data and safely add the new table to existing customers?
Ruby on Rails comes with ActiveRecord for database migrations. Does Grails comes with something like this out of the box?
Currently in development when I run my grails application after adding a new not null column to a table, I get column cannot be null exception thrown unless I delete that table in the database before running grails application which would recreate the table if not exists. Obviously once the application is deployed I will not have the luxury to delete the table.
Unfortunately, the current version of Grails doesn't come with database migration. However, there is a plugin for Liquibase which makes migrations possible.
The next version of Grails (1.4, planned for Q1 2011) will supposedly contain a built-in migration tool, which I am very much looking forward to.
Note: I haven't used the Liquibase plugin, so I don't have any firsthand experience with it. I have seen numerous blog posts describing its use, however, and I'm probably going to use it in my next Grails project if 1.4 isn't out by then.