[RUBY] LIMIT 11 lorsque les données sont acquises avec irb

J'utilise habituellement pry, donc je ne l'ai pas remarqué du tout, mais à un moment donné, je suis tombé sur un événement où lorsque j'ai utilisé irb, le mystère était limite 11.

Qu'est-ce que «LIMIT 11»! Je ne pouvais pas m'en empêcher, donc j'étais bâclé, mais je ne sais pas ... je suis inquiet. J'étais vraiment curieux, alors j'ai cherché et découvert pourquoi LIMIT 11 était attaché, alors j'ai écrit un article.

Confirmation de l'événement

Supposons que vous ayez un modèle comme celui-ci.

class User < ApplicationRecord
  has_many :reviews
end

class Review < ApplicationRecord
  belongs_to :user
end

Exécutons le processus pour obtenir les avis de l'utilisateur dans irb.

irb(main):006:0> user = User.find 1
  User Load (0.6ms)  SELECT `users`.* FROM `users` WHERE `users`.`id` = 1 LIMIT 1
=> #<User id: 1, name: "1234567890", created_at: "2019-12-12 05:43:52", updated_at: "2019-12-12 05:43:52">
irb(main):007:0> user.reviews
  Review Load (1.0ms)  SELECT `reviews`.* FROM `reviews` WHERE `reviews`.`user_id` = 1 LIMIT 11
=> #<ActiveRecord::Associations::CollectionProxy [#<Review id: 1, content: "hoge", user_id: 1, book_id: 0, status: "draft", created_at: "2020-06-11 05:27:55", updated_at: "2020-06-11 05:27:55">, #<Review id: 2, content: "fuga", user_id: 1, book_id: 0, status: "draft", created_at: "2020-06-11 05:45:12", updated_at: "2020-06-11 05:45:12">, #<Review id: 3, content: "fuga1", user_id: 1, book_id: 0, status: "draft", created_at: "2020-06-11 05:45:14", updated_at: "2020-06-11 05:45:14">, #<Review id: 4, content: "fuga12", user_id: 1, book_id: 0, status: "draft", created_at: "2020-06-11 05:45:15", updated_at: "2020-06-11 05:45:15">, #<Review id: 5, content: "fuga123", user_id: 1, book_id: 0, status: "draft", created_at: "2020-06-11 05:45:17", updated_at: "2020-06-11 05:45:17">, #<Review id: 6, content: "fuga1234]", user_id: 1, book_id: 0, status: "draft", created_at: "2020-06-11 05:45:18", updated_at: "2020-06-11 05:45:18">, #<Review id: 7, content: "fuga12345", user_id: 1, book_id: 0, status: "draft", created_at: "2020-06-11 05:45:20", updated_at: "2020-06-11 05:45:20">, #<Review id: 8, content: "fuga123456", user_id: 1, book_id: 0, status: "draft", created_at: "2020-06-11 05:45:22", updated_at: "2020-06-11 05:45:22">, #<Review id: 9, content: "fuga1234567", user_id: 1, book_id: 0, status: "draft", created_at: "2020-06-11 05:45:24", updated_at: "2020-06-11 05:45:24">, #<Review id: 10, content: "fuga12345678", user_id: 1, book_id: 0, status: "draft", created_at: "2020-06-11 05:45:27", updated_at: "2020-06-11 05:45:27">, ...]>
irb(main):008:0>

Il est livré avec LIMIT 11! Saviez-vous où c'était? Notez la requête émise par ʻuser.reviews`. Je mettrai l'image de la partie concernée sur ↓.

Pourquoi n'est-ce pas "LIMIT 11" même si je n'ai rien fait? Le voyage pour enquêter sur la cause commence ici.

Recherche de LIMIT 11 dans le référentiel Rails

Je me suis demandé si Rails faisait quelque chose, alors j'ai honnêtement cherché dans le référentiel Rails sur Github LIMIT 11.

35 articles ont été trouvés. C'est un niveau que vous pouvez atteindre visuellement, donc si vous jetez un coup d'œil rapide, ...

Il y avait un code comme ça!

Publié la méthode correspondante (lien vers Github ici)

activerecord/lib/active_record/relation.rb

def inspect
  subject = loaded? ? records : self
  entries = subject.take([limit_value, 11].compact.min).map!(&:inspect)

  entries[10] = "..." if entries.size == 11

  "#<#{self.class.name} [#{entries.join(', ')}]>"
end

Je pense que cela vient avec le nom de la méthode, mais il semble que LIMIT 11 soit ajouté lors de l'utilisation de ʻinspect`. En regardant le traitement, il semble que 10 éléments de données sont retournés et le 11ème élément est changé en "...".

Au fait, si vous ne connaissez pas ʻinspect`, veuillez vous référer à ici.

Renvoie une chaîne d'objets convertis au format lisible par l'homme.

Cette méthode est souvent utilisée lors du débogage.

J'ai trouvé que même le levier familier émettra LIMIT 11 si vous ajoutez ʻinspect`.

[12] pry(main)> user = User.find 1
  User Load (0.6ms)  SELECT `users`.* FROM `users` WHERE `users`.`id` = 1 LIMIT 1
=> #<User:0x00005599999f28a0
 id: 1,
 name: "1234567890",
 created_at: Thu, 12 Dec 2019 05:43:52 UTC +00:00,
 updated_at: Thu, 12 Dec 2019 05:43:52 UTC +00:00>
[13] pry(main)> user.reviews.inspect
  Review Load (0.6ms)  SELECT `reviews`.* FROM `reviews` WHERE `reviews`.`user_id` = 1 LIMIT 11
=> "#<ActiveRecord::Associations::CollectionProxy [#<Review id: 1, content: \"hoge\", user_id: 1, book_id: 0, status: \"draft\", created_at: \"2020-06-11 05:27:55\", updated_at: \"2020-06-11 05:27:55\">, #<Review id: 2, content: \"fuga\", user_id: 1, book_id: 0, status: \"draft\", created_at: \"2020-06-11 05:45:12\", updated_at: \"2020-06-11 05:45:12\">, #<Review id: 3, content: \"fuga1\", user_id: 1, book_id: 0, status: \"draft\", created_at: \"2020-06-11 05:45:14\", updated_at: \"2020-06-11 05:45:14\">, #<Review id: 4, content: \"fuga12\", user_id: 1, book_id: 0, status: \"draft\", created_at: \"2020-06-11 05:45:15\", updated_at: \"2020-06-11 05:45:15\">, #<Review id: 5, content: \"fuga123\", user_id: 1, book_id: 0, status: \"draft\", created_at: \"2020-06-11 05:45:17\", updated_at: \"2020-06-11 05:45:17\">, #<Review id: 6, content: \"fuga1234]\", user_id: 1, book_id: 0, status: \"draft\", created_at: \"2020-06-11 05:45:18\", updated_at: \"2020-06-11 05:45:18\">, #<Review id: 7, content: \"fuga12345\", user_id: 1, book_id: 0, status: \"draft\", created_at: \"2020-06-11 05:45:20\", updated_at: \"2020-06-11 05:45:20\">, #<Review id: 8, content: \"fuga123456\", user_id: 1, book_id: 0, status: \"draft\", created_at: \"2020-06-11 05:45:22\", updated_at: \"2020-06-11 05:45:22\">, #<Review id: 9, content: \"fuga1234567\", user_id: 1, book_id: 0, status: \"draft\", created_at: \"2020-06-11 05:45:24\", updated_at: \"2020-06-11 05:45:24\">, #<Review id: 10, content: \"fuga12345678\", user_id: 1, book_id: 0, status: \"draft\", created_at: \"2020-06-11 05:45:27\", updated_at: \"2020-06-11 05:45:27\">, ...]>"
[14] pry(main)>

Encore une fois, ce que fait «inspecter», c'est «retourner une chaîne d'objets convertis dans un format lisible par l'homme». Certes, même si une grande quantité de données est sortie, vous n'aurez pas envie de la lire visuellement, vous contrôlez donc d'afficher jusqu'à 10 pièces clairement!

Jusqu'à présent, j'ai trouvé quelque chose comme ça, mais ce n'est pas encore une solution. Parce que, dans irb, LIMIT 11 est attaché pour une raison quelconque même si ʻinspect` ne l'est pas.

irb LIMITE 11

Ensuite, concentrons-nous sur le résultat de la sortie lorsque la commande est exécutée avec irb. L'affichage des 11èmes données lorsque "LIMIT 11" est terminé est converti en "...". C'est exactement le comportement de ʻinspect` que j'ai étudié plus tôt.

Alors quand je suis allé avec «irb» et «inspect»

Utilisez Inspect pour la sortie des résultats! Lorsque j'ai cliqué dessus immédiatement, il était écrit comme suit. https://docs.ruby-lang.org/ja/latest/library/irb.html#inspect_mode

Vous pouvez changer la méthode de sortie des résultats en définissant l'une des valeurs suivantes dans conf.inspect_mode dans l'invite irb et dans IRB.conf [: INSPECT_MODE] dans le .irbrc. false, :to_s, :raw Le résultat de sortie to_s s'affiche. true, :p, :inspect Le résultat de sortie inspecté s'affiche. :pp, :pretty_inspect Le résultat de sortie s'affiche sous la forme pretty_inspect. :yaml, :YAML Affiche le résultat de sortie au format YAML. :marshal, :Marshal, :MARSHAL, Marshal Le résultat de la sortie est affiché comme Marshal. # Dump.

Lorsque je vérifie immédiatement la valeur par défaut,

irb(main):004:0> conf.inspect_mode
=> true

"Le résultat de sortie inspecté s'affiche." En raison de cet effet, il semble que ʻinspect soit toujours attaché même si ʻinspect n'est pas ajouté.

Je l'ai essayé avec un réglage différent (: pretty_inspect).

irb(main):010:0> conf.inspect_mode = :pp
=> :pp
- !ruby/object:Review
  concise_attributes:
irb(main):012:0> user = User.find 1
  User Load (0.8ms)  SELECT `users`.* FROM `users` WHERE `users`.`id` = 1 LIMIT 1
=> #<User:0x000055fcbd833780
 id: 1,
 name: "1234567890",
 created_at: Thu, 12 Dec 2019 05:43:52 UTC +00:00,
 updated_at: Thu, 12 Dec 2019 05:43:52 UTC +00:00>
irb(main):013:0> user.reviews
  Review Load (0.8ms)  SELECT `reviews`.* FROM `reviews` WHERE `reviews`.`user_id` = 1
=> [#<Review:0x000055fcbd87b120
  id: 1,
  content: "hoge",
  user_id: 1,
  book_id: 0,
  status: "draft",
  created_at: Thu, 11 Jun 2020 05:27:55 UTC +00:00,
  updated_at: Thu, 11 Jun 2020 05:27:55 UTC +00:00>,
 #<Review:0x000055fcbd87af68
  id: 2,
・ ・ ・ (Omis car il est long)

Il semble que «LIMIT 11» ne soit pas joint.

Ceci termine l'enquête. Ce sera rafraîchissant si vous comprenez bien la cause!

Résumé

À la suite de cette enquête, la cause de "LIMIT 11 lorsque les données sont acquises par irb" est

• Lorsque les données sont acquises avec ʻinspect, LIMIT 11` est automatiquement ajouté pour la lisibilité humaine.
• Si irb est utilisé avec les paramètres par défaut, ʻinspect` est automatiquement ajouté lorsque les données sont acquises.

était.

Cela peut avoir été un résultat utile dans le futur de trouver que «pretty_inspect» est plus facile à voir que «inspect »dans irb que la cause de« LIMIT 11 ».