I have a complicated SQL query that aggregates columns using a group_by.
IndividualOrder.select(SUM(...) as amount, other_fields).group_by("organization.id")
The problem is: I get an ActiveRecord::Relation from IndividualOrder, which isn't really what the result is conceptually anymore. I'm not entirely sure how to cast it to a new method. If I use arel to handle it, I still usually would have to go IndividualOrder.arel_table, and it would still cast to whatever I select.
I just want to take the fields [:amount, :organization, :other] and be able to interact with them as I would a database backed model that had those values as a table.
So, it's not quite a tableless model (which usually aren't database backed), and it's not an actual model because it's a generated query.
Is this the use case for scenic? I'm stuck with having to navigate around 2 variables that exist within the query that I'm doing via ActiveRecord.
Hi there hope this answer helps you, this should be a comment not a answer( not enough karma for doing that yet)
what you can do is to create a view in your database,
rails g migration my_new_view
ActiveRecord does not give us any methods to create views so you will have to do "manually" or you can use specific gems for doing those.
class MyNewView < ActiveRecord::Migration[5.2]
def change
reversible do |dir|
dir.up do
execute <<-SQL
CREATE OR REPLACE VIEW public.my_new_view AS
# your sql query here SELECT ....
SQL
end
dir.down do
execute <<-SQL
DROP VIEW IF EXISTS public.my_new_view;
SQL
end
end
end
end
now you can refer in your model.
Beware view tables will not show in schema by default, for seing them you have to put in your application.rb:
config.active_record.schema_format = :sql
cheers.
Related
with what migration can I add a column to every model at once? This would be handy almost every time you forgot to add a field anyway because most of the time a field you want to add is not limited to one model only. Like "email" In this case I forgot to add an "order" field.
Thanks
You can do as follows -
def change
tables = [:users, :products, :addresses]
tables.each do |table_name|
add_column table_name, :order, :integer
end
end
It's called a group migration
Answering your first question "With what migration can I add a column to every model at once?". Answer: None. Rails migrations are a way to alter database schemas over time in a consistent way.
Rails migrations are Ruby classes using Rails methods as instructions to modify your database as needed. So your question could be better formulated as "How can I create a migration to add a column to every model at once?"
IMHO I don't think there's going to be a specific method to do this, as the requeriment is pretty custom, but, depending in your Rails version you can get all the ApplicationRecord.descendants:
Zeitwerk::Loader.eager_load_all
ApplicationRecord.descendants.map { |table| table.name.downcase.pluralize }.each do |table|
add_column table, :logdate, :datetime
end
Or all those tables from the database that can be safe_constantized:
ActiveRecord::Base.connection.tables.map do |table|
table.classify.safe_constantize
end.reject(&:nil?).each do |table|
add_column table, :logdate, :datetime
end
That way you get the name of each table/model and use it as the first argument for add_column.
The difference is that in Rails 6 the default code loader is Zeitwerk, so you can eager load all the project dependencies. In other versions you could do the same but using Rails.application.eager_load!.
The second version would work without having to load the models as dependencies as it makes a query asking for their tables and then maps them as constants.
Right now my approach is to list every table one at a time and call .delete_all on it. Which is repetitive:
Example:
#app/db/seeds.rb
Blog.delete_all
Person.delete_all
Post.delete_all
User.delete_all
Author.delete_all
Book.delete_all
# ... on and on for all the tables
And then of course run rake db:seed which would clear out all the records for those above tables.
Is there a command that does exactly what I want:
deletes all the records from all the tables without deleting the tables themselves?
Or, is there a way to iterate through all my tables and .delete_all on each table?
Is there a command that does exactly what I want: deletes all the
records from all the tables?
bundle exec rake db:reset
This is functionally equivalent to rake db:drop db:setup.
Don't want delete the tables?
#app/db/seeds.rb
[Blog, Person, Post, User, Author, Book].each do |table|
ActiveRecord::Base.connection.execute("TRUNCATE #{table.table_name}")
end
SQL-TRUNCATE
As the OP has asked to delete all the record in all the tables, and not all the tables. So you can get all the tables by: ActiveRecord::Base.connection.tables, it will give you all you tables in the database.
puts ActiveRecord::Base.connection.tables
ActiveRecord::Base.connection.tables.each do |table|
next if table.match(/\Aschema_migrations\Z/)
klass = table.singularize.camelize.constantize
klass.delete_all
end
Edit:
If you do want id to start again from 1, when you create a new instance after emptying the table, you have to destroy the table, and re-create it.
ActiveRecord::Migration.drop_table(:users)
ActiveRecord::Migration.create_table(:users)
And now if you create a new instance of model User, it will start generating ids right from 1. Please note that you need to send the name of the table in drop_table, and create_table functions, while the code that I've written above gives you the name of the class, in this case User. You can get the table name if you have the name of the model:
User.table_name # it will give you "users"
# in above code, you can do:
ActiveRecord::Migration.drop_table(klass.table_name)
# string and symbol: both type of arguments work here!
If you really want to write ruby code to do this, try using ObjectSpace to get every instance of a Class, then select classes which inherit from ActiveRecord::Base
models = ObjectSpace.each_object(Class).select { |klass| klass < ActiveRecord::Base }
models.each{|m|m.delete_all}
However, the answers suggesting different rake tasks, instead of including this in seeds.rb are probably a better solution to your problem.
If you force rails to load all your models you can then iterate over them
Rails.application.eager_load!
# This only gets direct subclasses, since we are just deleting
# No reason to get their subclasses
models = ActiveRecord::Base.subclasses
models.each(&:delete_all)
I added those lines to my seeds.rb file. With this code, you don't have to bother with referencing manually your models and/or with foreign key constraints (thanks to disable_referential_integrity).
Rails.application.eager_load!
ActiveRecord::Base.connection.disable_referential_integrity do
ApplicationRecord.descendants.each do |model|
model.delete_all
end
end
NB : ApplicationRecord.descendants returns only true application models unlike ActiveRecord::Base.descendants (no more ApplicationRecord, schema_migrations and ar_internal_metadata).
I'm trying to write a very simple Rails migration that adds a new column to the table and populates it with a combination of data from other columns. However, the column gets added but the column value is nil for every record. What am I doing wrong?
class AddNameToPermissions < ActiveRecord::Migration
def change
add_column :auth_permissions, :name, :string
Auth::Permission.reset_column_information
Auth::Permission.all.each do |permission|
target_name = permission.target_symbol || permission.target_class
permission.name = permission.action << ", " << target_name
permission.save
end
end
end
Calling permission.save will execute all the callbacks including validators and maybe a validator is preventing the record to be saved. To skip validators you can use update_column instead of save
permission.update_column(:name, permission.action << ", " << target_name)
Also I would recommend you a couple of tips:
Use Auth::Permission.find_each instead of Auth::Permission.all.each (this loads all the records at once in memory)
Try to update the permission in a rake task and use only the migration to modify the table (it is the recommended good practice way)
Unless you are using the default option in a migration, it is usually advisable to do that in a custom rake task. Content Migrations are a bit of an anti pattern. The main Logic you want there is anything that has to deal with the schema of your database. Run your migration with only the add_column line, and then write a rake task to transfer the values from one table to the other.
To truncate an ActiveRecord table, I can do
Category.destroy_all
or
Post.destroy_all
How does one go about truncating a categories_post table?
For a true TRUNCATE, you can use execute to run the raw SQL.
ActiveRecord::Base.connection.execute("TRUNCATE TABLE #{table_name}")
Your examples using models weren't doing true TRUNCATE queries.
destroy_all does not TRUNCATE a table. It "destroys the records matching conditions by instantiating each record and calling its destroy method" (link).
delete_all is closer - it ignores callbacks - but still not a TRUNCATE.
Using the execute method deletes the rows from the database without creating any model instances.
Also, an actual TRUNCATE query, at least in MySQL, will reset the auto-increment on the primary key, so that the next record you insert will have id of 1.
I guess your join table is called categories_posts. CategoryPost.destroy_all should work, if not, maybe you need to specify the table name in the model (CategoryPost)
set_table_name "categories_posts"
Update, there isn't a CategoryPost model, so it should be created:
class CategoryPost < ActiveRecord::Base
set_table_name "categories_posts"
end
I'm trying to convert a column in my Rails app, for arguments sake let's pretend I'm trying to change the age column in my users table to a string representation rather than an int.
In my migration I have this;
def.self up
add_column :users, :age_text, :string
users = User.find(:all)
users.each do |u|
u.age_text = convert_to_text(u.age)
u.save
end
end
def self.convert_to_text(number)
#code here to convert 1 to 'one' etc
end
But it doesn't seem to be working, is what I'm attempting here even possible with migrations?
What you're trying to do is possible, and I would say the correct thing to do.
You need, though, to reload the column info for the model classes you're updating in the migration, so that Rails knows about the new columns. Try this:
def.self up
add_column :users, :age_text, :string
User.reset_column_information
users = User.find(:all)
users.each do |u|
u.age_text = convert_to_text(u.age)
u.save
end
end
On a separate note, please note that if your table is large, doing updates one by one will take a looong time.. Be careful with that.
Since I'm new here I can't comment on the above so I'll add my own answer.
GENERALLY manipulating data in migrations is a BAD idea. Migrations with direct model access can get stuck if the model logic changes.
Imagine in your second migration you've added a new column. You want to seed that column with new data.
Let's also say a few weeks later you add a new validation to the model - a validation that operates on a field that does not yet exist in your second migration. if you ever were to construct the database from migration 0, you'd have some problems.
I strongly suggest using migrations to alter columns and other means to manage database data, especially when moving to production.
Here is an example migration I ran to convert data. You can easily convert it to use integers instead of strings. Making the conversion in SQL is much faster than loading each row in Rails.
class ConvertCommentTextToText < ActiveRecord::Migration
def up
add_column :comments, :text_tmp, :text
# copy text column
execute <<-SQL
update comments set text_tmp = text
SQL
remove_column :comments, :text
rename_column :comments, :text_tmp, :text
end
def down
add_column :comments, :text_tmp, :string
# copy text column
execute <<-SQL
update comments set text_tmp = text
SQL
remove_column :comments, :text
rename_column :comments, :text_tmp, :text
end
end
And to test it:
rake db:migrate
rake db:rollback
rake db:migrate
I would say that if you can "undo" the imported data when rolling back the migration version, then it's appropriate to put imports into the migration.
For example, I have a migration which sets up a lot of lookup tables and other meta-data. The data for these tables are populated during this phase. As the data for these lookup tables changes, I create new YAML files storing the meta-data and load those files in subsequent migrations (and un-do those YAMLS, re-loading the previous YAML file when backing out of a migration version). This is pretty clean. I have files (in different well-defined folders in my case) with these files:
002_setup_meta_data.rb
002_meta_data.yaml
007_change_meta_data.rb
007_meta_data.yaml
If you're importing "production" data from another system into transactional (non-static) tables, then I would say using migrations is not appropriate. Then I would follow Brian Hogan's advice of using rake tasks.