Relied on the success of the previous call? Normally it would be a pain to checkĮach database success/failure status and then continue on in the chain. Have you ever had a situation in which you had multiple database calls that There are obvious performance concerns, but you can make the through path as long as you like.Using Ecto.Multi To Group Database Operations If links had yet another relationship and we wanted users to have many of that schema, then we could just add a third atom to the list. Here, the user schema specifies that it has many :bookmarks and the bookmark schema specifies that it belongs to :link, so we pass those directions as a list in through. In the example above, we have has_many(:bookmarked_links, through: ) We can give Ecto a path through multiple tables to create the join, by using the through option. The only problem is that links don't have a user_id on them. If it's something we want to do often, though, it's a lot more convenient to let Ecto take care of it, by defining a has_many relationship. We could even use Enum.filter to get a list of them. We could already access bookmarked links by doing a nested preload like bob = Repo.preload(bob, ]) and then accessing the link by looking at whats in the link attribute of each item in bob.bookmarks. It's entirely common to bookmark a site without labeling it "interesting" or "read later" or somehow categorize it. They may have bookmarked a given link or they may have tagged it (or both). Users have two distinct relationships with links. There is one interesting question, though. Many_to_many(:tags, Tag, join_through: LinkTag) Many_to_many(:tagged_links, Link, join_through: LinkTag) call the foreign key for links "link_id" in the join table and call the foreign key for user "user_id", etc), we can just pass the module name of the schema for the join table via the join_through option as below: defmodule Linkly.Link doĪlias Linkly. As long as we use the standard names for foreign keys in our tables (e.g. The third option is for arguments we can pass options to define how the tables are related to each other. The second argument is the module name of the schema. This is completely up to us to chose, but in general it's best to just use the name of the schema. The first argument is an atom that we want to use to access the associated records from in our schema. If a given link has been tagged with a given tag, then there will be a link_tag record with the appropriate foreign keys for links and tags are set.Īll we need to do to set up the many to many association in Ecto is to call the many_to_many/3 function in our schema definition. Similarly, links have a many-to-many relationship with tags and the "link_tags" join table also includes tag_id as foreign keys. If user #n has bookmarked link #m, then there will be a bookmark record with a user_id of n and a link_id of m. Instead, the relationship is tracked through the join table "link_tags", which has both link_ids and user_ids. The neither links nor users have the other as a foreign key in its schema. In our app, links have a many-to-many relationship to users. This time, we'll move on to many_to_many associations and also set up some has_many through associations. , we covered has_many and belongs_to associations and saw some of the conveniences Ecto offers once associations are defined. This episode we'll add tags to our project and create more advanced associations.
0 Comments
Leave a Reply. |