I've been coding with ruby & ruby on rails. And in rails, when you build relations between models, there always was foreign key(like user_id or post_id). How does coredata works? I didnt add any foreign key, but somehow it works
ps sorry for newbie question
Same as with Rails Active Record, Core Data is an ORM. You don't need to specify which foreign key (user_id etc) to use, and the ORM will use name conventions to use one. Check the actual DB tables and you will find the foreign_key column there.
Related
We have a SAAS platform written in Rails using the postgres' schema based multitenancy and Apartment gem. The different schemas are identical, with same number of tables and same columns in each table. We want to migrate to foreign key based multitenant system where we want to merge all the records from different schemas into a single schema, identifying each record with a tenant_id. What is the proper way of merging all the records from the different schemas, and preserving the foreign key relationships.
This is a situation that will need care. I think (I could be wrong) that the best approach is to add to all tables tenant_id and original_id ... before attempting migration populate original_id in all tables with id of that record. Essentially this is to have a record of what the value of id was before the merging.
After merge you can then run a rake task that rebuilds the associations. So if you had...
class Foo
has_many :bars
Your migration script would do (after migration)
Bar.all.each do |bar|
foo = Foo.find_by(tenant_id: bar.tenant_id, original_id: bar.foo_id)
bar.update_column(:foo_id, foo.id)
end
You'd need to do something similar for every relation, so it's a bit of a slog.
Hopefully, someone else will come up with a better solution.
NOTE THIS IS NOT IDEMPOTENT. If it errors, you can't restart it except by redoing the merging completely.
I developed a Ruby on Rails 5 application and deployed it to a production environment, after running rake db:migrate I noticed that I wasn't using foreign_key: true and neither index: true for my general relations between tables. Question is: Will this affect database performance and should I generate new migrations just to add indexes and foreign keys references to my columns? Thanks in advance.
From Ruby on Rails guide:
2.2 Schema Conventions
Active Record uses naming conventions for the columns in database tables, depending on the purpose of these columns.
Foreign keys - These fields should be named following the pattern
singularized_table_name_id (e.g., item_id, order_id). These are the
fields that Active Record will look for when you create associations
between your models.
Primary keys - By default, Active Record will use an integer column
named id as the table's primary key. When using Active Record
Migrations to create your tables, this column will be automatically
created.
You must know more about ActiveRecord Look here how it works here
I suggest you to read about belongs_to and has_many relations
Depends on what you are going to do, if you have relations where the foreign key is needed, you will need to create those migrations, otherwise you wont be able to access them.
When it comes to db performance it doesnt matter really
How can I create postgres db for Rails app properly but in psql, not via rake db:create?
I mean, one can always write CREATE DATABASE project_name, but I don't know what happens in that rake task under the hood. Maybe there are a lot of additional params.
Update
After first answer I decided to clarify: I know how to write and use migrations, they are awesome, but my question not about them. It's about rake db:create task and pg adapter.
In other words, I just want to know which command in psql is equal to rake db:create.
If you select the db on pgadmin III it will show you the sql instructions with the local things to load. They are very importanst if you have full text index on. You must run them from the database postgres.
Rails expects table names to match model names but be plural and snake_case. For example, a User model will store records in a users table and a BlogEntry model will store records in a blog_entries table.
Rails expects a table's primary key to be named id and it expects foreign keys to match model names but be snake_case and end with _id. For example, if BlogEntry belongs_to User, Rails will expect the blog_entries table to have a user_id column.
Join tables (such as used with many-to-many relations) are expected to be named with the two models' names in plural snake case and alphabetical order. For example, a join table describing a many-to-many relation between a User model and a Blog model would be expected to have the name blogs_users and have, at the least, the columns blog_id and user_id.
Those are the basics. Of course, all of this is configurable: For example, you can use the table_name class method to tell a model to use a table with a different name, and the relation methods (belongs_to, has_many, etc.) all take options letting you specify different names.
Apart from these naming conventions Rails doesn't require anything special from a database, as long as the correct credentials and configuration are specified in config/database.yml.
It's not hard to do this thick,also it hides all logic in model,so it also fits the philosophy of rails model.
So I am wondering if there is some good reasons of handtyping foreign-keys inside the migration files.
You don't have to do it by hand. For example:
rails g model post user:references
creates migration adding posts table with user_id column and index on this column.
This issue has been around since Rails 1. There were arguments for and against but at that time, the various db vendors differed substantially in their particular syntax for foreign key constraints and it was non trivial to implement across multiple db vendors. At least that was my understanding at that time
So when I define an association in rails do I have to set the foreign key as an index in the database?
My friend told me to do this to improve performance, but he is a PHP programmer.
Yes your friend is correct it will help the database get the answer for your query faster