Rails: si has_many de la relation changé

J'ai ces deux classes. 

class Article < ActiveRecord::Base
  attr_accessible :body, :issue, :name, :page, :image, :video, :brand_ids
  has_many :publications
  has_many :docs, :through => :publications
end

class Doc < ActiveRecord::Base
  attr_accessible :issue_id, :cover_id, :message, :article_ids, :user_id, :created_at, :updated_at, :issue_code, :title, :template_id
  has_many :publications, dependent: :destroy
  has_many :articles, :through => :publications, :order => 'publications.position'
  has_many :edits, dependent: :destroy
  accepts_nested_attributes_for :articles, allow_destroy: false
end

Comment pourrais-je écrire une instruction conditionnelle pour voir si @doc.articles a changé après la mise à jour @doc?

if @doc.articles.changed?
  ...
end

Ci-dessus me donne une erreur. Je ne trouve pas la bonne syntaxe.

InformationsquelleAutor okay56k | 2013-05-24
  1. 20

    Vous avez à vérifier chacune. .changed? ne fonctionne que sur un seul enregistrement. Vous pourriez faire quelque chose comme cela si vous avez besoin de vérifier l'ensemble de l'association depuis au moins un changement d':

    if @doc.articles.find_index {|a| a.changed?} then...

    Ou vous pouvez utiliser Enumerable#any?:

    if @doc.articles.any? {|a| a.changed?} then...
    • Quid du cas où un has_many est ajouté à la liste? C'est un changement, mais il sera détecté de cette façon?
    • Est-il un moyen de détecter si @personne.task_ids_changed?. J'aimerais savoir si le _ids tableau des changements.
    • Vous pouvez aussi l'écrire comme @doc.articles.any?(&:changed?)
    • Cela ne semble pas fonctionner pour le cas où un objet associé a été ajoutée ou supprimée.
    • oui, c'est vrai. Le changé? méthode spécifiquement indique si un attribut existant a changé de valeur, ou si un nouveau a été ajouté, mais pas encore enregistré dans la base de données. L'OP ne veut pas dire qu'ils veulent inclure le retrait ou l'ajout d'un article.
    • Si vous souhaitez également compte lorsqu'un objet correspondant a été ajouté ou supprimé, vous pourriez faire @doc.articles.any?(&:changed?) || @doc.articles.collect(&:id).sort != @doc.articles.pluck(&:id).sort. Cela fonctionne parce que collect va tirer l'id de la mémoire associations (y compris nil éléments dans le tableau ne sont pas encore enregistré associations, et à l'exclusion des identifiants de la matrice pour être supprimé associations), tandis que pluck tire les identifiants de la base de données (qui fait le contraire, à l'exclusion n'est pas encore enregistré de l'association des id et notamment à être supprimé de l'association id).

    InformationsquelleAutor lurker
  2. 7

    Un peu en retard, mais pour d'autres personnes qui sont à la recherche d'une solution similaire, vous pouvez détecter les changements dans la Relation (aussi has_and_belongs_to_many) de cette manière:

    class Article < ActiveRecord::Base
attr_accessible :body, :issue, :name, :page, :image, :video, :brand_ids
has_many :publications
has_many :docs, :through => :publications
end
class Doc < ActiveRecord::Base
attr_accessible :issue_id, :cover_id, :message, :article_ids, :user_id, :created_at, :updated_at, :issue_code, :title, :template_id
has_many :publications, dependent: :destroy
has_many :articles, :through => :publications, :order => 'publications.position'
has_many :edits, dependent: :destroy
accepts_nested_attributes_for :articles, allow_destroy: false
after_initialize :initialize_article_changes_safe
after_save :change_articles
after_save :initialize_article_changes
before_add_for_articles << ->(method,owner,change) { owner.send(:on_add_article, change) }
before_remove_for_articles << ->(method,owner,change) { owner.send(:on_remove_article, change) }
def articles_changed?
@article_changes[:removed].present? or @article_changes[:added].present?
end
private
def on_add_article(article)
initialize_article_changes_safe
@article_changes[:added] << article.id
end
def on_remove_article(article)
initialize_article_changes_safe
@article_changes[:removed] << article.id
end
def initialize_article_changes
@article_changes = {added: [], removed: []}
end
def initialize_article_changes_safe
@article_changes = {added: [], removed: []} if @article_changes.nil?
end
def unchanged_article_ids
self.article_ids - @article_changes[:added] - @article_changes[:removed]
end
def change_articles
do_stuff if self.articles_changed?
do_stuff_for_added_articles unless @article_changes[:added].nil?
do_stuff_for_removed_articles unless @article_changes[:removed].nil?
end
end

    Les deux crochets before_add_for_NAME-OF-RELATION et before_remove_for_NAME-OF-RELATION sont déclenchés lors de l'ajout ou de la suppression d'une relation. Le déclenchée fonctions (on ne peut pas lier une fonction par son nom, vous devez le faire par lambda) ajouter l'id de l'ajoutés /supprimés relation des éléments à la @articel_changes de hachage. Lorsque le modèle est enregistré, vous pouvez gérer les objets par leur id dans la change_articles fonction. Après cela, le @articel_changes de hachage sera effacé.

    • Cela semble trop compliqué compte tenu de rails que vous avez before_add, after_add, before_remove, after_remove rappels vous pouvez définir dans les associations.
    • c'est à droite sur la relation normale, mais pas sur un has_and_belongs_to_many relation. Le has_and_belongs_to_many table de relation est sans clés primaires et ne contient que les deux ids. Donc, même si vous obtenez un déclencheur dans les crochets, il est très difficile à obtenir l'id de l'objet cible pendant le processus de changement. Une autre solution est de créer une table intermédiaire et aussi un modèle intermédiaire. mais que vous avez un classique 1:n relation.
    InformationsquelleAutor Sebastian Hegge
  3. 2

    J'ai trouvé Énumérable#tout? utile avec une étape intermédiaire à l'inversion de trier par id dans la manière suivante:

    @doc.articles.sort { |a, b| b.id <=> a.id }.any?(&:changed?)

    Ce genre étape permet de tout? pour revenir au début, au lieu de boucle dans les anciens article dossiers pour savoir si la modification a été faite.

    Pour, par exemple, dans mon cas, j'ai eu un has_many :event_responders relation et après l'ajout d'un nouveau EventResponder de la collection, je l'ai validé la ci-dessus pour travailler dans la manière suivante:

    Sans l'aide d'un intermédiaire de tri

    2.2.1 :019 > ep.event_responders.any? { |a| puts a.changes; a.changed? }
{}
{}
{}
{}
{"created_at"=>[Thu, 03 Sep 2015 08:25:59 UTC +00:00, Thu, 03 Sep 2015 08:25:59 UTC +00:00], "updated_at"=>[Thu, 03 Sep 2015 08:25:59 UTC +00:00, Thu, 03 Sep 2015 08:25:59 UTC +00:00]}
=> true

    À l'aide d'un intermédiaire de tri

    2.2.1 :020 > ep.event_responders.sort { |a, b| b.id <=> a.id }.any? { |a| puts a.changes; a.changed? }
{"created_at"=>[Thu, 03 Sep 2015 08:25:59 UTC +00:00, Thu, 03 Sep 2015 08:25:59 UTC +00:00], "updated_at"=>[Thu, 03 Sep 2015 08:25:59 UTC +00:00, Thu, 03 Sep 2015 08:25:59 UTC +00:00]}
=> true

    Grâce.

    InformationsquelleAutor Jignesh Gohel