[{"_1":2,"_160":-5,"_161":-5},"loaderData",{"_3":4,"_38":-5,"_39":40,"_132":133,"_158":-5,"_159":-5},"root",{"_5":-5,"_6":-5,"_7":8,"_22":23,"_24":25,"_26":27,"_30":31,"_36":37},"user","shoppingCartId","shoppingCart",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20,"_21":14},"id","no-cart","count",0,"free",true,"updatedAt","","paymentGateway","STRIPE","cartItems",[],"loading","locale","en","readerTheme","light","constants",{"_28":29},"paypalClientId","AX53Cwz8jR6rVVzzZiZNWWXl0dGagi-GZrjG-S3Ua14E5nrKMn7DxDQ730O4R8LusLPp49ALn6aRVaEy","publishers",{"_32":33,"_34":35},"companies",[],"universities",[],"needsLocaleCookieSync",false,"routes/_store+/_readers+/read_/route","routes/_store+/_readers+/read_.$slug/route",{"_41":42,"_67":68,"_125":126,"_130":37,"_131":-7},"book",{"_43":44,"_45":46,"_47":48,"_49":50,"_53":54,"_56":57,"_65":66},"title","Conhecendo Rails","slug","conhecendo-rails","metaText","Livro direto e bem mão na massa que explica o funcionamento e recursos do framework Rails, feito em Ruby.","coverFeatured",{"_51":52},"url","https://d2sofvawe08yqg.cloudfront.net/conhecendo-rails/s_featured?1620383325&1620383325","coverFeatured2x",{"_51":55},"https://d2sofvawe08yqg.cloudfront.net/conhecendo-rails/s_featured2x?1620383325&1620383325","authors",[58],{"_9":59,"_60":61,"_5":62},"Z2lkOi8vbGVhbnB1Yi9TdG9yZTo6UHJvZHVjdEF1dGhvci82MTQ2","name","Eustáquio Rangel de Oliveira Jr.",{"_63":64},"username","taq","showReadLinkString","sample","parts",[69],{"_43":44,"_70":16,"_71":12,"_72":73},"description","fileCount","chapters",[74,93,121],{"_75":76,"_43":77,"_78":79,"_71":80,"_81":82,"_89":-5},"level",2,"Sobre esse livro","path","#leanpub-auto-sobre-esse-livro",1,"subsections",[83,90],{"_75":84,"_43":85,"_70":-5,"_78":86,"_71":80,"_87":-5,"_88":-5,"_89":-5},3,"Contato","#leanpub-auto-contato","quizType","sectionNum","youtubeId",{"_75":84,"_43":91,"_70":-5,"_78":92,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Convenções utilizadas","#leanpub-auto-convenes-utilizadas",{"_75":76,"_43":94,"_78":95,"_71":80,"_81":96,"_89":-5},"Associações entre modelos","#leanpub-auto-associaes-entre-modelos",[97,100,103,106,109,112,115,118],{"_75":84,"_43":98,"_70":-5,"_78":99,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Associação do tipo um-para-um","#leanpub-auto-associao-do-tipo-um-para-um",{"_75":84,"_43":101,"_70":-5,"_78":102,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Associação do tipo um-para-muitos","#leanpub-auto-associao-do-tipo-um-para-muitos",{"_75":84,"_43":104,"_70":-5,"_78":105,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Associações de muitos para muitos","#leanpub-auto-associaes-de-muitos-para-muitos",{"_75":84,"_43":107,"_70":-5,"_78":108,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Associações de muitos para muitos, através","#leanpub-auto-associaes-de-muitos-para-muitos-atravs",{"_75":84,"_43":110,"_70":-5,"_78":111,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Acelerando as consultas nas associações","#leanpub-auto-acelerando-as-consultas-nas-associaes",{"_75":84,"_43":113,"_70":-5,"_78":114,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Juntando joins e includes","#leanpub-auto-juntando-joins-e-includes",{"_75":84,"_43":116,"_70":-5,"_78":117,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Pluck versus select","#leanpub-auto-pluck-versus-select",{"_75":84,"_43":119,"_70":-5,"_78":120,"_71":80,"_87":-5,"_88":-5,"_89":-5},"Criando um outro tipo de associação um-para-um","#leanpub-auto-criando-um-outro-tipo-de-associao-um-para-um",{"_75":76,"_43":122,"_78":123,"_71":80,"_81":124,"_89":-5},"Notes","#leanpub-endnotes",[],"toc",[127,83,90,128,97,100,103,106,109,112,115,118,129],{"_75":76,"_43":77,"_70":-5,"_78":79,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":94,"_70":-5,"_78":95,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":122,"_70":-5,"_78":123,"_71":80,"_87":-5,"_88":-5,"_89":-5},"isUnavailableOnline","unavailableMessage","routes/_store+/_readers+/read_.$slug.$chapterId/route",{"_43":44,"_134":135,"_41":136,"_155":-5,"_156":157},"content","

Notes

1http://bluefish.com.br↩

\n\n

2https://dl.dropboxusercontent.com/u/1482800/javaversusrubybooks.jpeg↩

\n\n

3http://leanpub.com/conhecendo-ruby↩

\n\n

4https://pt.wikipedia.org/wiki/Chave_estrangeira↩

\n\n\n

",{"_137":138,"_43":44,"_47":48,"_45":46,"_65":66,"_139":140,"_154":135},"previewContent","

Sumário

\n Sobre esse livro\n
- \n Contato\n
- \n Convenções utilizadas\n
\n
\n Associações entre modelos\n
- \n Associação do tipo um-para-um\n
- \n Associação do tipo um-para-muitos\n
- \n Associações de muitos para muitos\n
- \n Associações de muitos para muitos, através\n
- \n Acelerando as consultas nas associações\n
- \n Juntando joins e includes\n
- \n Pluck versus select\n
- \n Criando um outro tipo de associação um-para-um\n
\n
\n Notes\n

\n\n

Nenhuma parte desta publicação pode ser reproduzida, armazenada em bancos de\ndados ou transmitida sob qualquer forma ou meio, seja eletrônico, eletrostático,\nmecânico, por fotocópia, gravação, mídia magnética ou algum outro modo, sem\npermissão por escrito do detentor do copyright.

\n\n

Ilustração da capa por Ana Carolina Otero Rangel.

\n\n

Sobre esse livro

\n\n

Alguns anos atrás, mais precisamente em 22 de Abril de 2006, lancei um dos\nprimeiros tutoriais de Rails daqui do Brasil, bem curtinho e mão na massa,\nseguido pelo “desaforo” monstro (no bom sentido) de 300 páginas do Ronaldo\nFerraz, “Rails para sua diversão e lucro”, que na minha opinião foi o material\nque foi mais utilizado para impulsionar o framework por aqui. Pena que depois\ndele o Ronaldo não escreveu mais nada, pois a desenvoltura e eloquência dele\npara explicar o tema e metodologias associadas são ótimas.

\n\n

Durante todos esses anos, venho trabalhado com Rails como ferramenta de\npreferência para projetos web, só não o utilizando se for algum requisito de\nprojeto do cliente utilizar alguma outra linguagem (geralmente, para a parte\nweb, PHP), mas venho negando algumas situações desse tipo por ter ficado mal\nacostumado com a qualidade e facilidade que o Rails proporciona as nossas\naplicações. Sério, não é porque eu escrevi o primeiro livro de Ruby do Brasil ou\ncoisa do tipo, eu costumo promover as coisas que eu realmente acredito que sejam\nboas.

\n\n

Além de trabalhar com Rails, já ministrei muitos treinamentos, tanto em Ruby\ncomo Rails, através de cursos organizados por mim mesmo ou minha empresa, a\nBluefish ¹, ou de cursos de mini-cursos de Rails em faculdades e\nempresas. Minha meta nesse livro é tentar chegar no mesmo ponto em que eu chego\natravés do material que levo e dos vários “extras” dos treinamentos ao vivo,\napresentando o framework para quem está chegando agora e dando algum pitaco\naqui ou ali das tecnologias associadas, apesar de acreditar que nunca vou\nconseguir chegar no ponto das aulas presenciais, pois eu falo mais que o homem\nda cobra e faço um monte de macaquices nos treinamentos. Enfim, é uma tentativa.

\n\n

Nesse livro, basicamente vamos ver o que já vem embutido com o Rails, sem\nutilizar (muito) algumas outras gems que atualmente são bastante utilizadas e\npopulares. Minha meta é mostrar como é o framework assim que “sai da caixa”, e\nmostrar como fazer determinadas coisas com os recursos mínimos apresentados e\nentregues por ele. Aqui e ali vão existir algumas dicas de como dar uma\nincrementada em determinada feature, mas esperem encontrar aqui um Rails\npuro-sangue, sem muitas modificações ou extras. Existem alguns outros livros\nmuito interessantes, recomendados, a respeito desses outros recursos que podem e\nalgumas vezes, devem ser utilizados para o desenvolvimento de uma aplicação\nRails, mas existe também um certo exagero em ensinar o framework, chegando ao\nponto de ficar parecido com uma piadinha antiga sobre uma pilha de livros de\nJava necessários para aprender Java e dois livros para aprender Rails\n². Hoje em dia, se não tomarmos cuidado, a coisa se inverte. Por isso\nque, mesmo abrindo mão de ensinar algumas coisas mais “cool” por aqui, minha\nmeta é ensinar como desenvolver com Ruby on Rails em apenas um livro.

\n\n

Acredito que para quem está chegando agora, é uma didática interessante. Alguns\npodem até me criticar depois por coisa do tipo “mas porque diabos ele me fez\nescrever tanto código se dava para usar somente uma gem” ou “porque ele não me\nmostrou a tecnologia X que é muito chique, e eu quero ser chique”, mas ninguém\nvai poder me criticar por mostrar como implementar determinados comportamentos e\nfeatures com os recursos mínimos disponíveis, que no final, até reduzem\ndeterminadas facilidades que podem ser tornar complexidades. Espero que gostem.

\n\n

Como complemento, e para quem está conhecendo o framework agora, fica a dica\nde ler o meu outro ebook, “Conhecendo Ruby”³. Para quem está\nconhecendo o framework antes da linguagem, parem tudo: leiam o livro sobre\na linguagem e depois voltem por aqui, senão algumas das coisas que o Rails faz\nvão parecer bruxaria ou alguma coisa do tinhoso. A urgência de começar com uma\naplicação no framework sem conhecer a linguagem em que ele é feito pode até\nser justificada por algum prazo apertado ou mesmo a ânsia de meter logo a mão na\nmassa, mas acreditem, vocês vão perder uma ótima chance de entender mais o\nframework logo no início se não conhecerem a linguagem Ruby de uma forma\nbásica antes.

\n\n

Ah, e tudo o que é mostrado aqui foi executado em um sistema operacional\nGNU/Linux. Rails vai rodar melhor em sistemas Unix like como Linux e o OSX\n(com certeza utilizando um Linux como servidor de produção), e com algum\nesforço, no Windows. Mas não me peçam dicas para esse último, está fora do\nescopo aqui do livro e até do meu dia-a-dia.

\n\n

Contato

\n\n

Meu site é http://eustaquiorangel.com, meu Twitter\né @taq e meu Github é\nhttp://github.com/taq.

\n\n

Convenções utilizadas

\n\n

Durante o livro temos algumas convenções:

\n\n

Texto em itálico para palavras não tão tradicionais no nosso Português;
Texto em negrito para destacar alguma informação importante;
Texto em fonte de tamanho fixo para código;
Linhas iniciadas com $ indicam que estão sendo executadas em um terminal;
Em partes de código ou comandos no terminal em que forem encontrados três\npontos (...), signifjca que acima ou abaixo dos pontos existe conteúdo que\nfoi omitido para que não fosse apresentado todo o código. Também pode ser\nutilizado para indicar algumas operações como inserir conteúdo em um arquivo e\nlogo após executar um comando no terminal;
Encontrando essa barra \\ no final de uma linha de código significa que a\nlinha continua abaixo;

\n\n

E temos algumas caixas de informações como:

\n\n\n\n\n\n\n\n\n

Associações entre modelos

\n\n

Para testar as associações entre os nossos modelos, temos que criar um novo,\npois só temos um. Vamos criar um scaffold novo com o modelo Book, que terá\nos seguintes atributos:

\n\n

\ntitle - Título
\npublished_at - Data de publicação
\ntext - Texto descritivo do livro
\nvalue - Valor do livro
\nperson_id - Autor do livro

\n\n

Criando o novo scaffold:

\n\n

1 $ rails g scaffold Book title:string published_at:date text:text value:decima\\\n2 l person:references\n3       invoke  active_record\n4       create    db/migrate/20170311144612_create_books.rb\n5       create    app/models/book.rb\n6       invoke    test_unit\n7       create      test/models/book_test.rb\n8       create      test/fixtures/books.yml\n9       ...\n

\n\n\n\n

Agora é adaptar e rodar as migrations, alterar os testes unitários e\nfuncionais, limitar o acesso ao controlador de livros para somente quem tiver\nfeito o login, verificar o layout do controlador e rodar os testes para ver se\nestá tudo ok.

\n\n

Nem vamos escrever por aqui como faz isso, pois é basicamente o que fizemos com\no controlador de pessoas, somente algumas observações para a migration, vista\naqui já alterada:

\n\n

 1 class CreateBooks < ActiveRecord::Migration[5.0]\n 2   def change\n 3     create_table :books do |t|\n 4       t.string :title, limit: 100, null: false\n 5       t.date :published_at, null: false\n 6       t.text :text, null: false\n 7       t.decimal :value, precision: 10, scale: 2, null: false\n 8       t.references :person, foreign_key: true\n 9       t.timestamps\n10     end\n11   end\n12 end\n

\n\n\n\n

Dando uma olhada no que customizamos nas colunas da tabela do banco de dados:

\n\n

A coluna title vai ter um limite de 100 caracteres (limit: 100) e não \npode ter o seu valor nulo (null: false).
A coluna published_at não pode ter o seu valor nulo.
A coluna text não pode ter o seu valor nulo.
A coluna value não pode ter o seu valor nulo, tem que ter precisão de 10\ndígitos (precision: 10) sendo que 2 digitos (scale: 2) são utilizados como\ncasas decimais, ou seja, temos um tamanho de 8 dígitos antes da casa decimal.
Foi criada uma referência para outra tabela, através de :person (ou seja,\nreferenciando a tabela People, de acordo com as convenções), sendo definida\ncomo chave estrangeira⁴. Isso leva a criar uma coluna chamada\nperson_id na tabela Book, que é a chave estrangeira que aponta para o id\nda tabela People que está referenciado em person_id.

\n\n

Vamos adaptar a nossa fixture de livro:

\n\n

 1 one:\n 2    title: Conhecendo Ruby\n 3    published_at: 2013-06-29\n 4    text: Livro prático sobre a linguagem Ruby\n 5    value: 1.00\n 6    person: admin\n 7 \n 8 two:\n 9    title: Conhecendo o Git\n10    published_at: 2013-06-24\n11    text: Quer aprender Git de forma rápida e prática? \n12    value: 10.00 \n13    person: admin\n

\n\n\n\n

Reparem que utilizei, ao invés de person_id, o nome da associação,\nperson, e a chave da fixture de pessoas, admin, para indicar na fixture\nque o livro está associado com a pessoa da outra fixture. Eu poderia ter\nutilizado autor, mas fui xarope e utilizei admin para fazer propagandas dos\nmeus livros e ebooks. ;-)

\n\n

Isso funciona pois automagicamente quando utilizamos references ao criar a\nmigration, o Rails já embutiu código dentro do modelo, que vamos ver logo\nabaixo. Antes de mais nada vamos alterar nossos testes (que, após a adaptação da\nfixture acima já devem estar rodando de boa) para refletir o comportamento\nque queremos que o modelo do livro apresente, seja baseado no que definimos no\nbanco de dados (que é o que vamos fazer aqui, limitar pelas constraints\ninseridas no banco) ou em alguma regra específica para ele.

\n\n

Vamos alterar nosso teste do modelo Book, presente em\ntest/models/book_test.rb para:

\n\n

 1 require 'test_helper'\n 2 \n 3 class BookTest < ActiveSupport::TestCase\n 4   setup do\n 5     @book = books(:one)\n 6   end\n 7 \n 8   # título\n 9   test 'deve ter um título' do\n10     @book.title = nil\n11     assert !@book.valid?\n12   end\n13 \n14   test 'não pode ter mais que 100 caracteres' do\n15     @book.title = '*' * 101\n16     assert !@book.valid?\n17   end\n18 \n19   # data de publicação\n20   test 'deve ter data de publicação' do\n21     @book.title = nil\n22     assert !@book.valid?\n23   end\n24 \n25   # texto\n26   test 'deve ter texto' do\n27     @book.text = nil\n28     assert !@book.valid?\n29   end\n30 \n31   # valor\n32   test 'deve ter valor' do\n33     @book.value = nil\n34     assert !@book.valid?\n35   end\n36 \n37   test 'deve ser um número' do\n38     @book.value = 'bla'\n39     assert !@book.valid?\n40   end\n41 \n42   test 'não deve ser maior que o permitido' do\n43     @book.value = 100000000.00\n44     assert !@book.valid?\n45   end\n46 \n47   # pessoa\n48   test 'deve ter pessoa' do\n49     @book.person = nil\n50     assert !@book.valid?\n51   end\n52 end\n

\n\n\n\n\n\n

Associação do tipo um-para-um

\n\n

Nosso livro (o da aplicação, não esse que você está lendo) precisa de uma pessoa\nque seja o autor, que desejamos acessar como um método chamado person, em um\nobjeto representando um livro. Esse foi um dos testes que inserimos acima, o\núltimo, por sinal, no arquivo de teste unitário de livro.

\n\n

Vamos dar uma olhada em arquivo do modelo de Book, ainda sem as validações\nnecessárias para passar nos testes, mas já com o resultado da automagicamente\ncriada coluna especificada na migration através de references:

\n\n

1 class Book < ApplicationRecord\n2   belongs_to :person\n3 end\n

\n\n\n\n

Ali no modelo foi indicado automagicamente (lógico que podemos inserir e alterar\nisso na hora que quisermos) que um livro pertence à uma pessoa, utilizando o\nmétodo belongs_to, ou seja pertence à. Dessa forma, foi criada uma\nassociação no ORM indicando uma dependência (forte, por sinal, é uma foreign\nkey do livro para a pessoa.

\n\n

Essa associação, por padrão, a partir do Rails 5, não pode ficar vazia, ou\nseja, se um livro pertence à uma pessoa, deve obrigatoriamente conter um\nregistro válido, uma foreign key válida, ali. Se por acaso desejarmos por\nalgum motivo que essa verificação seja afrouxada, podemos especificar no final a\nHash optional: true, dessa forma:

\n\n

1 class Book < ApplicationRecord\n2   belongs_to :person, optional: true\n3 end\n

\n\n\n\n

Isso é útil para migrar aplicações de versões anteriores que permitiam esse\ncomportamento. Podemos até definir esse comportamento para a aplicação inteira,\nutilizando o seguinte código em um initializer:

\n\n

1 Rails.application.config.active_record.belongs_to_required_by_default = false\n

\n\n\n\n

Mas vamos deixar sem o optional e manter o que já vem definido por padrão.

\n\n

Vamos terminar de inserir as validações necessárias para o modelo passar nos\ntestes:

\n\n

 1 class Book < ApplicationRecord\n 2   validates :title, presence: true, length: { maximum: 100 }\n 3   validates :published_at, presence: true\n 4   validates :text, presence: true\n 5   validates :value, presence: true, numericality: { less_than_or_equal_to: 99\\\n 6 999999.99 }\n 7   validates :person, presence: true\n 8 \n 9   belongs_to :person\n10 end\n

\n\n\n\n

Vamos ver como funcionam essas validações logo mais no livro, mas tem algumas\nali que até já são auto-explicativas. Se rodarmos nossos testes agora, todos\ndevem passar.

\n\n

Como temos a associação com pessoa, em nossos objetos de livros, ela já pode ser\ntestada no console ou no navegador:

\n\n

 1 book = Book.new\n 2 => #<Book id: nil, title: nil, published_at: nil, text: nil, value: nil, pers\\\n 3 on_id: nil, created_at: nil, updated_at: nil> \n 4 \n 5 book.title = \"Ruby - Conhecendo a Linguagem\"\n 6 => \"Ruby - Conhecendo a Linguagem\" \n 7 \n 8 book.published_at = \"2006-03-01\"\n 9 => \"2006-03-01\" \n10 \n11 book.text = \"Tinha, mas acabou.\"\n12 => \"Tinha, mas acabou.\" \n13 \n14 book.value = 40.00\n15 => 40.0 \n16 \n17 book.person = Person.last\n18 Person Load (0.3ms)  SELECT \"people\".* FROM \"people\" ORDER BY name DESC LIMIT\\\n19  1\n20 => #<Person id: 2, name: \"Eustáquio Rangel\", email: \"taq@bluefish.com.br\",\n21 password: \"9733340c840c719779f234407ee0bac26ae8904b\", born_at: \"1971-04-06\",\n22 admin: true, created_at: \"2013-07-06 22:51:34\", updated_at: \"2013-07-07\n23 22:48:20\"> \n24 \n25 book.person.name\n26 => \"Eustáquio Rangel\" \n27 \n28 book.save\n29 (0.1ms)  begin transaction\n30 SQL (28.9ms)  INSERT INTO \"books\" (\"created_at\", \"person_id\", \"published_at\",\n31 \"text\", \"title\", \"updated_at\", \"value\") VALUES (?, ?, ?, ?, ?, ?, ?)\n32 [[\"created_at\", Tue, 09 Jul 2013 15:15:46 UTC +00:00], [\"person_id\", 2],\n33 [\"published_at\", Wed, 01 Mar 2006], [\"text\", \"Tinha, mas acabou.\"], [\"title\",\n34 \"Ruby - Conhecendo a Linguagem\"], [\"updated_at\", Tue, 09 Jul 2013 15:15:46 UTC\n35 +00:00], [\"value\", #<BigDecimal:ae70608,'0.4E2',9(45)>]]\n36 (114.1ms)  commit transaction\n37 => true \n

\n\n\n\n

Ficando assim:

\n\n\n

\n\n\n

Associação do tipo um-para-muitos

\n\n

Já que um livro pertence à uma pessoa, agora podemos especificar que uma pessoa\npode ter vários livros. Primeiro, no teste unitário:

\n\n

1 test \"deve ter uma coleção de livros\" do\n2   person = people(:admin)\n3   assert_respond_to person, :books\n4   assert_kind_of Book, person.books.first\n5 end\n

\n\n\n\n

E no modelo, estabelecendo a associação, usando has_many:

\n\n

1     has_many :books\n

\n\n\n\n

Através do has_many temos uma coleção de livros no objeto da pessoa, como\npodemos verificar pelo console:

\n\n

 1 p = Person.last\n 2 Person Load (0.3ms)  SELECT \"people\".* FROM \"people\" ORDER BY name DESC LIMIT\\\n 3  1\n 4 => #<Person id: 2, name: \"Eustáquio Rangel\", email: \"taq@bluefish.com.br\",\n 5 password: \"9733340c840c719779f234407ee0bac26ae8904b\", born_at: \"1971-04-06\",\n 6 admin: true, created_at: \"2013-07-06 22:51:34\", updated_at: \"2013-07-07\n 7 22:48:20\"> \n 8 \n 9 p.books\n10 Book Load (0.1ms)  SELECT \"books\".* FROM \"books\" WHERE \"books\".\"person_id\" = 2\n11 => [#<Book id: 1, title: \"Ruby - Conhecendo a Linguagem\", published_at:\n12 \"2006-03-01\", text: \"Tinha, mas acabou.\", value:\n13 #<BigDecimal:aaae9c0,'0.4E2',9(36)>, person_id: 2, created_at: \"2013-07-09\n14 15:15:46\", updated_at: \"2013-07-09 15:15:46\">] \n15 \n16 p.book_ids\n17 => [1] \n18 \n19 p.books.last.title\n20 => \"Ruby - Conhecendo a Linguagem\" \n

\n\n\n\n

Ficando assim:

\n\n\n

Fica aqui uma dica sobre o que acontece quando apagamos o registro da pessoa com\nvários livros. O comportamento padrão é não-intrusivo e não faz nada, mas\npodemos especificar o que deve ser feito através de :dependent, da seguinte\nforma:

\n\n

1 has_many :books, dependent: :destroy\n

\n\n\n\n

Os seguintes comportamentos estão disponíveis para :dependent:

\n\n

\ndestroy - Os objetos associados são destruídos junto com o objeto\ncorrente, chamando os métodos destroy de cada objeto.
\ndelete_all - Os objetos associados são apagados sem chamar o método\ndestroy de cada um.
\nnullify - Todas as chaves estrangeiras dos objetos associados são\ntransformadas em nulo, sem chamar os callbacks de atualização dos objetos.
\nrestrict_with_error - Evita que o objeto seja apagado, retornando false\nse tem mais objetos associados.
\nrestrict_with_exception - Evita que o objeto seja apagado, disparando uma\nexceção se tem mais objetos associados.

\n\n\n\n

Podemos fazer testes unitários em Person para verificar que o comportamento de\n:restrict_with_exception ou :destroy são obedecidos, e para termos certeza\nde que o modelo está configurado corretamente de acordo com a nossa escolha.

\n\n

Para o teste de :restrict_with_exception, nesse caso alterando o modelo para

\n\n

1 has_many :books, dependent: :restrict_with_exception\n

\n\n\n\n

podemos utilizar:

\n\n

 1 test \"não pode apagar a pessoa se ela tiver livros\" do\n 2   person = people(:admin)\n 3   assert person.books.size > 0\n 4 \n 5   assert_no_difference('Person.count') do\n 6     assert_no_difference('Book.count') do\n 7       assert_raise ActiveRecord::DeleteRestrictionError do\n 8         assert !person.destroy, \"não deveria apagar com #{person.books.size} \\\n 9 livro(s)\"\n10       end\n11     end\n12   end\n13 end\n

\n\n\n\n

Rodando os testes, podemos ver que tudo está funcionando de acordo. Agora, para\no teste de :destroy, vamos alterar o modelo para

\n\n

1 has_many :books, dependent: :destroy\n

\n\n\n\n

e nos testes podemos comentar o teste anterior e inserir o seguinte código:

\n\n

 1 test \"deve apagar os livros quando apagar a pessoa\" do\n 2   person = people(:admin)\n 3   assert person.books.size > 0\n 4 \n 5   assert_difference('Person.count', -1) do\n 6     assert_difference('Book.count',person.books.size * -1) do\n 7       assert person.destroy, \"deveria apagar a pessoa\"\n 8     end\n 9   end\n10 end\n

\n\n\n\n

Podemos notar que o primeiro comportamento e teste é para evitar que a pessoa\nseja apagada se tiver itens na coleção, chutando o pau da barraca e disparando\numa Exception se isso ocorrer, enquanto que o segundo é para garantir que os\nitens da coleção sejam apagados se a pessoa for apagada.

\n\n\n\n

Associações de muitos para muitos

\n\n

Vamos criar um novo scaffold para cadastrarmos as categorias que nossos livros\npertencem. Os livros cadastrados até aqui já pertencem à duas categorias que\npodemos definir como “tecnologia” e “programação”. Vamos criar mais um\nscaffold bem simples para gerenciar as categorias, e já rodar as migrations:

\n\n

1 $ rails g scaffold Category name:string\n2       invoke  active_record\n3       create    db/migrate/20170312135948_create_categories.rb\n4       create    app/models/category.rb\n5       invoke    test_unit\n6 $ rails db:migrate\n

\n\n\n\n

Após o scaffold criado, podemos acessar http://localhost:3000/categories e\ncriar as categorias mencionadas acima. Se quiserem adicionar outras para ver\ncomo fica a seleção, fiquem à vontade. Vamos adaptar também as fixtures\ncriadas para refletir nas chaves algo mais identificável nas categorias, não\nesquecendo de trocar nos testes funcionais as chaves onde está sendo\nreferenciado one para alguma das que vamos criar agora:

\n\n

1 tech:\n2   name: Tecnologia\n3 \n4 dev:\n5   name: Desenvolvimento\n

\n\n\n\n

Para deixar as categorias disponíveis no gerenciamento de livros, no controlador\nde livros devemos pedir para que sejam carregadas, através do método\nbefore_action:

\n\n

 1 class BooksController < ApplicationController\n 2   before_action :set_book, only: [:show, :edit, :update, :destroy]\n 3   before_action :load_categories, only: [:new, :edit, :create, :update]\n 4   ...\n 5 \n 6   private\n 7   def load_categories\n 8      @categories = Category.all\n 9   end\n10   ...\n11 end\n

\n\n\n\n

Agora que temos disponíveis as categorias, precisamos de um meio de indicar que\num livro tem várias categorias, e que a categoria tem vários livros. Para isso\nvamos utilizar uma tabela auxiliar, ou join table, para armazenar o id do\nlivro e os ids (zero ou mais) das categorias dos livros. Vamos utilizar o método\nhas_and_belongs_to_many, que até o Rails 4 ficou na controvérsia se seria\nainda utilizado ou se seria marcado como deprecated, mas que até agora está\nfuncionando muito bem, e é bem simples de implementar.

\n\n

Vamos criar a join table com os nomes dos dois modelos, em ordem\nalfabética, isso é muito importante, criando a seguinte migration:

\n\n

1 $ rails g migration CreateJoinTableBookCategory book category\n2       invoke  active_record\n3       create    db/migrate/20170312145600_create_join_table_book_category.rb\n

\n\n\n\n

Ela vai ter um conteúdo como esse, já removidos os comentários:

\n\n

1 class CreateJoinTableBookCategory < ActiveRecord::Migration[5.0]\n2   def change\n3     create_join_table :books, :categories do |t|\n4       t.index [:book_id, :category_id]\n5       t.index [:category_id, :book_id]\n6     end\n7   end\n8 end\n

\n\n\n\n

Rodando a migration, vai ser criada a tabela books_categories, que não vai\nter um modelo associado, e nem um id. Esses são detalhes muito importantes em\numa join table desse tipo:

\n\n

1 $ rails db:migrate\n2 == 20170312145600 CreateJoinTableBookCategory: migrating ====================\\\n3 ==\n4 -- create_join_table(:books, :categories)\n5    -> 0.0076s\n6    == 20170312145600 CreateJoinTableBookCategory: migrated (0.0076s)\n7    =============\n

\n\n\n\n

Agora vamos indicar no modelo de livro que ele tem vários relacionamentos com\nesse modelo novo, e que tem várias categorias. Antes de mais nada, testes no\nmodelo de livro:

\n\n

1 # categorias\n2 test 'deve ter categorias' do\n3   assert_respond_to @book, :categories\n4 end\n5 \n6 test 'deve ter categorias do tipo correto' do\n7   @book.categories << categories(:one)\n8   assert_kind_of Category, @book.categories.first\n9 end\n

\n\n\n\n

E agora sim podemos alterar o modelo de livro indicando que ele pertence à\nvárias categorias:

\n\n

1 class Book < ApplicationRecord\n2   ...\n3   has_and_belongs_to_many :categories\n4   ...\n5 end\n

\n\n\n\n

Isso nos dá os seguintes métodos em Book:

\n\n

 1 > b = Book.first\n 2   Book Load (0.1ms)  SELECT  \"books\".* FROM \"books\" ORDER BY \"books\".\"id\" ASC\n 3   LIMIT ?  [[\"LIMIT\", 1]] => #<Book id: 14, title: \"Conhecendo Ruby\",\n 4   published_at: \"2013-06-29\", text: \"Livro prático sobre a linguagem Ruby\",\n 5   value: #<BigDecimal:1701a10,'0.1E1',9(18)>, person_id: 15, created_at:\n 6   \"2017-03-12 15:22:07\", updated_at: \"2017-03-12 15:22:07\"> \n 7 \n 8 > b.categories\n 9   Category Load (0.2ms)  SELECT \"categories\".* FROM \"categories\" INNER JOIN\n10   \"books_categories\" ON \"categories\".\"id\" = \"books_categories\".\"category_id\"\n11   WHERE \"books_categories\".\"book_id\" = ?  [[\"book_id\", 14]] =>\n12   #<ActiveRecord::Associations::CollectionProxy [#<Category id: 1, name:\n13   \"Tecnologia\", created_at: \"2017-03-12 14:02:51\", updated_at: \"2017-03-12\n14   14:02:51\">, #<Category id: 2, name: \"Programação\", created_at: \"2017-03-12\n15   14:02:51\", updated_at: \"2017-03-12 14:02:51\">]> \n16 \n17 > b.category_ids\n18  => [1, 2] \n

\n\n\n\n

E agora podemos fazer a mesma coisa no modelo de categoria:

\n\n

1 class Category < ApplicationRecord\n2   has_and_belongs_to_many :books\n3 end\n

\n\n\n\n

Que nos dá os métodos:

\n\n

 1 > c = Category.first\n 2 Category Load (0.4ms)  SELECT  \"categories\".* FROM \"categories\" ORDER BY\n 3 \"categories\".\"id\" ASC LIMIT ?  [[\"LIMIT\", 1]]\n 4 => #<Category id: 1, name: \"Tecnologia\", created_at: \"2017-03-12 14:02:51\",\n 5 updated_at: \"2017-03-12 14:02:51\"> \n 6 \n 7 > c.books\n 8   Book Load (0.3ms)  SELECT \"books\".* FROM \"books\" INNER JOIN \"books_categori\\\n 9 es\"\n10   ON \"books\".\"id\" = \"books_categories\".\"book_id\" WHERE\n11   \"books_categories\".\"category_id\" = ?  [[\"category_id\", 1]] =>\n12   #<ActiveRecord::Associations::CollectionProxy [#<Book id: 14, title:\n13   \"Conhecendo Ruby\", published_at: \"2013-06-29\", text: \"Livro prático sobre a\n14   linguagem Ruby\", value: #<BigDecimal:3799958,'0.1E1',9(18)>, person_id: 15,\n15   created_at: \"2017-03-12 15:22:07\", updated_at: \"2017-03-12 15:22:07\">, #<Bo\\\n16 ok\n17   id: 15, title: \"Conhecendo o Git\", published_at: \"2013-06-24\", text: \"Quer\n18   aprender Git de forma rápida e prática?\", value:\n19   #<BigDecimal:378fef8,'0.1E2',9(18)>, person_id: 15, created_at: \"2017-03-12\n20   15:22:07\", updated_at: \"2017-03-12 15:22:07\">]> \n21 \n22 > c.book_ids\n23  => [14, 15] \n

\n\n\n\n

Ficando assim:

\n\n\n

\n\n\n

Vamos aproveitar o método category_ids de Book para fazer a nossa escolha de\ncategorias. Primeiro, vamos liberar nos strong parameters do controlador dos\nlivros o envio desse atributo, dessa forma:

\n\n

1 def book_params\n2   params.require(:book).permit(:title, :published_at, :text, :value, :person_\\\n3 id, category_ids: [])\n4 end\n

\n\n\n\n\n\n

E listamos as categorias disponíveis no formulário dos livros em\napp/views/books/_form.html.erb através da coleção já presente no controlador\nna variável @categories, com o método collection_check_boxes:

\n\n

1   <div class=\"field\">\n2     <h2>Categorias</h2>  \n3     <%= collection_check_boxes :book, :category_ids, @categories, :id, :name \\\n4 %>\n5   </div>\n

\n\n\n\n

O que vai nos dar uma lista com as categorias cadastradas na forma de\ncheckboxes no formulário de edição dos livros. Ficou legal, mas podemos\nmelhorar para deixar com uma semântica mais adequada. Particularmente, eu\nprefiro gerar um elemento ul com um elemento li para cada categoria. Podemos\npersonalizar da seguinte forma:

\n\n

1 <ul>\n2 <%= collection_check_boxes :book, :category_ids, @categories, :id, :name do |\\\n3 builder| %>\n4   <li>\n5     <%= builder.label { builder.check_box + builder.text } %>\n6   </li>\n7 <% end %>\n8 </ul>\n

\n\n\n\n

Agora sim ficou legal. Vamos alterar a view\napp/views/books/show.html.erb para listar as categorias cadastradas do livro:

\n\n

1 <h2>Categorias</h2>\n2 <ul>\n3   <% for category in @book.categories %>\n4     <li><%= category.name %></li>\n5   <% end %>\n6 </ul>\n

\n\n\n\n

Associações de muitos para muitos, através

\n\n

Agora que temos uma pessoa com vários livros, um livro que pertence à uma pessoa\ne tem várias categorias, sendo que uma categoria tem vários livros, podemos\npensar o seguinte: e se quisermos saber quais as categorias de livros que\numa pessoa tem? Podemos ver que está tudo conectado na modelagem conforme\ndescrito, só precisamos de um jeito de, quando estivemos na pessoa, recuperarmos\na categoria através (essa palavra é muito importante) aqui dos livros. Para\nisso, vamos usar a associação has_many :through. Primeiro, vamos alterar a\nfixture dos livros para incluírem as categorias, enviadas como um Array,\ndessa forma:

\n\n

 1 one:\n 2   title: Conhecendo Ruby\n 3   published_at: 2013-06-29\n 4   text: Livro prático sobre a linguagem Ruby\n 5   value: 1.00\n 6   person: admin\n 7   categories: [ tech, dev ]\n 8 \n 9 two:\n10   title: Conhecendo o Git\n11   published_at: 2013-06-24\n12   text: Quer aprender Git de forma rápida e prática? \n13   value: 10.00 \n14   person: admin\n15   categories: [ tech, dev ]\n

\n\n\n\n

Agora um teste de pessoa:

\n\n

 1 # categorias\n 2 test 'deve ter várias categorias, através de livros' do\n 3   assert_respond_to @person, :categories\n 4 end\n 5 \n 6 test 'deve ter uma categoria do tipo correto' do\n 7   assert_kind_of Category, @person.categories.first\n 8 end\n 9 \n10 test 'deve ter apenas duas categorias' do\n11   assert_equal 2, @person.categories.count\n12 end\n

\n\n\n\n

Convém atentar para o último teste. Ele procura garantir que são encontradas\napenas 2 categorias, mas temos 2 livros com 2 categorias cada um, de modo que\nvão ser retornadas 4 categorias. Vamos resolver isso já, mas antes vamos ver\no método tradicional de indicar que pessoa tem várias categorias através de\nlivro, inserindo no arquivo do modelo de pessoa a seguinte linha:

\n\n

1 ...\n2 has_many :categories, through: :books\n3 ...\n

\n\n\n\n

Novamente, uma configuração bem simples, que nos dá as categorias da pessoa:

\n\n

 1 > Person.last.categories\n 2   Person Load (0.4ms)  SELECT  \"people\".* FROM \"people\" ORDER BY \"people\".\"na\\\n 3 me\"\n 4   DESC LIMIT ?  [[\"LIMIT\", 1]] Category Load (0.1ms)  SELECT \"categories\".* F\\\n 5 ROM\n 6   \"categories\" INNER JOIN \"books_categories\" ON \"categories\".\"id\" =\n 7   \"books_categories\".\"category_id\" INNER JOIN \"books\" ON\n 8   \"books_categories\".\"book_id\" = \"books\".\"id\" WHERE \"books\".\"person_id\" = ?\n 9   [[\"person_id\", 15]]\n10  => #<ActiveRecord::Associations::CollectionProxy [#<Category id: 1, name:\n11  \"Tecnologia\", created_at: \"2017-03-12 14:02:51\", updated_at: \"2017-03-12\n12  14:02:51\">, #<Category id: 2, name: \"Programação\", created_at: \"2017-03-12\n13  14:02:51\", updated_at: \"2017-03-12 14:02:51\">, #<Category id: 1, name:\n14  \"Tecnologia\", created_at: \"2017-03-12 14:02:51\", updated_at: \"2017-03-12\n15  14:02:51\">, #<Category id: 2, name: \"Programação\", created_at: \"2017-03-12\n16  14:02:51\", updated_at: \"2017-03-12 14:02:51\">]> \n

\n\n\n\n

Só que, como já identificamos no teste, vai trazer as categorias repetidas. Para\nevitar isso, precisamos pegar os resultados distintos, e se alguém conhece SQL\npor aí, sabe que isso podemos recuperar com uma cláusula DISTINCT, que é o que\nvamos utilizar enviando através de uma lambda para a associação:

\n\n

1 has_many :categories, -> { distinct }, through: :books\n

\n\n\n\n

Pronto! Agora rodando os testes, vamos constatar que as categorias estão\nretornando corretamente, sem duplicação.

\n\n

Essa associação ficou da seguinte forma, representada pelo traço pontilhado:

\n\n\n

Acelerando as consultas nas associações

\n\n

Temos alguns jeitos de utilizarmos as associações, sendo que estamos vendo até\nagora o jeito padrão que já vem com o Rails, onde o ORM cuida de bastante\ncoisas para nós, mas onde também podemos dar uma mãozinha para que as coisas\nfiquem mais eficientes.

\n\n

Joins

\n\n

Vamos imaginar que queremos descobrir as pessoas que tem livros associados. \nUm jeito de não fazer isso seria assim:

\n\n

1 > Person.select { |person| person.books.count > 0 }\n2   Person Load (0.1ms)  SELECT \"people\".* FROM \"people\" ORDER BY \"people\".\"nam\\\n3 e\" ASC\n4    (0.1ms)  SELECT COUNT(*) FROM \"books\" WHERE \"books\".\"person_id\" = ?  [[\"pe\\\n5 rson_id\", 4]]\n6    (0.1ms)  SELECT COUNT(*) FROM \"books\" WHERE \"books\".\"person_id\" = ?  [[\"pe\\\n7 rson_id\", 3]]\n

\n\n\n\n

Vejam que eu percorremos toda a tabela de pessoas e estamos fazendo várias\noutras consultas para pegar cada pessoa e selecionar os livros de cada uma\ndelas. Ficou uma mistura de iteradores Ruby (o método select) com código SQL\n(o where dentro de cada bloco). Podemos fazer bem melhor utilizando joins:

\n\n

1 Person.joins(:books).distinct\n2   Person Load (0.2ms)  SELECT DISTINCT \"people\".* FROM \"people\" INNER JOIN\n3   \"books\" ON \"books\".\"person_id\" = \"people\".\"id\" ORDER BY \"people\".\"name\" ASC\n4  => #<ActiveRecord::Relation [#<Person id: 3, name: \"Eustáquio Rangel de\n5  Oliveira Jr.\", email: \"taq@bluefish.com.br\", password_digest: ...\n

\n\n\n\n

Bem melhor, não? Ali o INNER JOIN produzido pelo método joins já relacionou\nas duas tabelas, fazendo o filtro de uma vez só no comando SQL, procurando\nobrigatoriamente pessoas que tem livros. Vejam que utilizamos distinct no\nfinal, para evitar registros duplicados se a pessoa tiver mais de um livro.

\n\n\n\n

Includes

\n\n

Temos um problema ali: e se precisarmos saber os títulos dos livros encontrados?\nO resultado nos trouxe somente uma coleção de objetos tipo Person.

\n\n

Vamos fazer um teste:

\n\n

1 > Person.joins(:books).distinct.map { |person| { person.name => person.books.\\\n2 pluck(:title) } }\n3   Person Load (0.3ms)  SELECT DISTINCT \"people\".* FROM \"people\" INNER JOIN\n4   \"books\" ON \"books\".\"person_id\" = \"people\".\"id\" ORDER BY \"people\".\"name\" ASC\n5    (0.1ms)  SELECT \"books\".\"title\" FROM \"books\" WHERE \"books\".\"person_id\" = ?\\\n6   [[\"person_id\", 3]]\n7  => [{\"Eustáquio Rangel de Oliveira Jr.\"=>[\"Conhecendo Ruby\", \"Conhecendo o G\\\n8 it\"]}]\n

\n\n\n\n

Reparem que para cada pessoa, foi executada outra consulta para recuperar os\nlivros (e também o nome da pessoa, como chave da Hash) e retornar somente o\ntítulo. O que ocorre é o método joins estabelece o relacionamento, mas não\ndeixa disponivel os dados da outra associação, não faz eager\nloading. Para\nremediar isso, podemos utilizar o método includes.

\n\n

Antes de aplicarmos o método includes na nossa consulta, vale mencionar que\nele também pode ser utilizado, além do eager loading, como um LEFT OUTER\nJOIN:

\n\n

1 Person.includes(:books).distinct.map { |person| { person.name => person.books\\\n2 .pluck(:title) } }\n3   Person Load (0.1ms)  SELECT DISTINCT \"people\".* FROM \"people\" ORDER BY \"peo\\\n4 ple\".\"name\" ASC\n5   Book Load (0.4ms)  SELECT \"books\".* FROM \"books\" WHERE \"books\".\"person_id\" \\\n6 IN (4, 3)\n7  => [{\"Ana Carolina\"=>[]}, {\"Eustáquio Rangel de Oliveira Jr.\"=>[\"Conhecendo \\\n8 Ruby\", \"Conhecendo o Git\"]}]\n

\n\n\n\n

Podemos ver que para as pessoas que não tinham livros, foi retornado uma coleção\nvazia e que ao invés de várias consultas aos livros (o que ocorreria se\ntivéssemos várias pessoas com livros) foi feita uma, especificando os ids de\ntodas as pessoas.

\n\n

Juntando joins e includes

\n\n

Mas vamos voltar para resolver nosso problema de performance. Se pensarmos que\njoins faz a associação com a outra tabela e includes faz o eager loading,\né só juntarmos os dois:

\n\n

 1 > Person.joins(:books).includes(:books).distinct.map { |person| { person.name\\\n 2  => person.books.pluck(:title) } }\n 3   SQL (0.2ms)  SELECT DISTINCT \"people\".\"id\" AS t0_r0, \"people\".\"name\" AS t0_\\\n 4 r1,\n 5   \"people\".\"email\" AS t0_r2, \"people\".\"password_digest\" AS t0_r3,\n 6   \"people\".\"born_at\" AS t0_r4, \"people\".\"admin\" AS t0_r5, \"people\".\"created_a\\\n 7 t\"\n 8   AS t0_r6, \"people\".\"updated_at\" AS t0_r7, \"books\".\"id\" AS t1_r0,\n 9   \"books\".\"title\" AS t1_r1, \"books\".\"published_at\" AS t1_r2, \"books\".\"text\" AS\n10   t1_r3, \"books\".\"value\" AS t1_r4, \"books\".\"person_id\" AS t1_r5,\n11   \"books\".\"created_at\" AS t1_r6, \"books\".\"updated_at\" AS t1_r7, \"books\".\"stoc\\\n12 k\"\n13   AS t1_r8, \"books\".\"lock_version\" AS t1_r9 FROM \"people\" INNER JOIN \"books\" \\\n14 ON\n15   \"books\".\"person_id\" = \"people\".\"id\" ORDER BY \"people\".\"name\" ASC\n16  => [{\"Eustáquio Rangel de Oliveira Jr.\"=>[\"Conhecendo Ruby\", \"Conhecendo o G\\\n17 it\"]}]\n

\n\n\n\n

Agora sim! Temos uma consulta única de onde são extraídas todas as informações\nque precisamos. Vejam como o ORM altera o nome dos campos e sabe acessar cada\num de maneira transparente.

\n\n

Pluck versus select

\n\n

Vimos que utilizamos o método pluck. Esse método extrai somente os atributos\nque indicamos, sem retornar um objeto da associação. Assim:

\n\n

1 > Person.pluck(:name)\n2    (0.3ms)  SELECT \"people\".\"name\" FROM \"people\" ORDER BY \"people\".\"name\" ASC\n3  => [\"Ana Carolina\", \"Eustáquio Rangel de Oliveira Jr.\"] \n

\n\n\n\n

Podemos indicar mais de um atributo:

\n\n

1 > Person.pluck(:name, :email)\n2    (0.2ms)  SELECT \"people\".\"name\", \"people\".\"email\" FROM \"people\" ORDER BY \"\\\n3 people\".\"name\" ASC\n4  => [[\"Ana Carolina\", \"carol@bluefish.com.br\"], [\"Eustáquio Rangel de Oliveir\\\n5 a Jr.\", \"taq@bluefish.com.br\"]]\n

\n\n\n\n

Vejam que são retornados POROs (Plain Old Ruby Objects), no formato de\nArrays.

\n\n

O método select, por sua vez, retorna um objeto com apenas os atributos\nselecionados preenchidos, ou seja, não vamos conseguir acessar os outros.\nAssim, isso funciona:

\n\n

 1 > Person.select(:name, :email)\n 2   Person Load (0.1ms)  SELECT \"people\".\"name\", \"people\".\"email\" FROM \"people\"\n 3   ORDER BY \"people\".\"name\" ASC => #<ActiveRecord::Relation [#<Person id: nil,\n 4   name: \"Ana Carolina\", email: \"carol@bluefish.com.br\">, #<Person id: nil, na\\\n 5 me:\n 6   \"Eustáquio Rangel de Oliveira Jr.\", email: \"taq@bluefish.com.br\">]> \n 7 \n 8 > Person.select(:name, :email).first.name\n 9   Person Load (0.3ms)  SELECT  \"people\".\"name\", \"people\".\"email\" FROM \"people\"\n10   ORDER BY \"people\".\"name\" ASC LIMIT ?  [[\"LIMIT\", 1]]\n11  => \"Ana Carolina\" \n12 \n13 > Person.select(:name, :email).first.email\n14   Person Load (0.2ms)  SELECT  \"people\".\"name\", \"people\".\"email\" FROM \"people\"\n15   ORDER BY \"people\".\"name\" ASC LIMIT ?  [[\"LIMIT\", 1]]\n16  => \"carol@bluefish.com.br\" \n

\n\n\n\n

Já isso, não:

\n\n

1 > Person.select(:name, :email).first.admin\n2   Person Load (0.1ms)  SELECT  \"people\".\"name\", \"people\".\"email\" FROM \"people\"\n3   ORDER BY \"people\".\"name\" ASC LIMIT ?  [[\"LIMIT\", 1]]\n4 ActiveModel::MissingAttributeError: missing attribute: admin\n

\n\n\n\n

Criando um outro tipo de associação um-para-um

\n\n

Podemos utilizar um outro tipo de associação um-para-um, com uma semântica\ndiferente, utilizando has_one. Enquanto que em belongs_to a foreign key\nestava no modelo que especificava a relação, em has_one está no outro\nmodelo.

\n\n

Podemos, por exemplo, dizer que as pessoas da nossa aplicação tem cada uma, uma\nimagem. Para isso, vamos aprender como fazer upload de arquivos.

\n\n

Notes

1http://bluefish.com.br↩

\n\n

2https://dl.dropboxusercontent.com/u/1482800/javaversusrubybooks.jpeg↩

\n\n

3http://leanpub.com/conhecendo-ruby↩

\n\n

4https://pt.wikipedia.org/wiki/Chave_estrangeira↩

\n\n\n

\n\n

\n\n","tocStructure",[141,142,143,144,145,146,147,148,149,150,151,152,153],{"_75":76,"_43":77,"_70":-5,"_78":79,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":85,"_70":-5,"_78":86,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":91,"_70":-5,"_78":92,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":94,"_70":-5,"_78":95,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":98,"_70":-5,"_78":99,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":101,"_70":-5,"_78":102,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":104,"_70":-5,"_78":105,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":107,"_70":-5,"_78":108,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":110,"_70":-5,"_78":111,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":113,"_70":-5,"_78":114,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":116,"_70":-5,"_78":117,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":119,"_70":-5,"_78":120,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":122,"_70":-5,"_78":123,"_71":80,"_87":-5,"_88":-5,"_89":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]