92 Matching Annotations
  1. Dec 2023
  2. Aug 2023
    1. As you say, you can use after_add and after_remove callbacks. Additionally set after_commit filter for association models and notify "parent" about change. class User < ActiveRecord::Base has_many :articles, :after_add => :read, :after_remove => :read def read(article) # ;-) end end class Article < ActiveRecord::Base belongs_to :user after_commit { user.read(self) } end
    2. As you say, you can use after_add and after_remove callbacks. Additionally set after_commit filter for association models and notify "parent" about change. class User < ActiveRecord::Base has_many :articles, :after_add => :read, :after_remove => :read def read(article) # ;-) end end class Article < ActiveRecord::Base belongs_to :user after_commit { user.read(self) } end
  3. Mar 2023
  4. Jan 2023
  5. Dec 2022
  6. Nov 2022
    1. Post.in_order_of(:type, %w[Draft Published Archived]).order(:created_at).pluck(:name) which generates SELECT posts.name FROM posts ORDER BY CASE posts.type WHEN 'Draft' THEN 1 WHEN 'Published' THEN 2 WHEN 'Archived' THEN 3 ELSE 4 END ASC, posts.created_at ASC
  7. May 2022
  8. Apr 2022
  9. Mar 2022
  10. Feb 2022
    1. personally, i think this is useful when you have objects which are not stored in database, as shown in the database, e.g. temperature, gps location, balance, etc. You might ask then why those are not stored in the database? In the database we only store a value, but if we want to attach useful, relevant methods to that value,
  11. Nov 2021
  12. Jul 2021
  13. Jun 2021
  14. Feb 2021
    1. Record filters allow you to require an instance of a particular class (or one of its subclasses) or a value that can be used to locate an instance of the object. If the value does not match, it will call find on the class of the record. This is particularly useful when working with ActiveRecord objects.
    1. I have a Post object that has_one :schedule with accepts_nested_attributes_for :schedule as well. The latter method sets autosave: true, which unfortunately has the effect of hoisting up errors into the parent object so that the errors object on Post looks like this: (byebug) post.errors.details {:"schedule.publish_at"=>[{:error=>:blank}]}
    1. array :translations do hash do string :locale string :name end end array inputs can only have one input nested underneath them. This is because every element of the array must be the same type. And the inputs nested inside arrays cannot have names because they would never be used.
    1. So how are we going to create a model that doesn’t have a database table behind it? There are several potential solutions including various plugins but we’re going to use the method described in an entry on the Code Tunes blog. This shows a techinque that involves overriding a couple of methods in an ActiveRecord model and then manually defining the columns in the model file rather than in the database table. In our Recommendation model we’ll add in the two overridden methods and then use the column class method to define the columns in a similar way to how they’re defined in a migration file.

      Does this still work in Rails 6? I wonder.

    1. Set your models free from the accepts_nested_attributes_for helper. Action Form provides an object-oriented approach to represent your forms by building a form object, rather than relying on Active Record internals for doing this.

      It seems that the primary/only goal/purpose was to provide a better alternative to ActiveRecord's accepts_nested_attributes_for.

      Unfortunately, this appears to be abandoned.

    1. Set your models free from the accepts_nested_attributes_for helper. Active Form provides an object-oriented approach to represent your forms by building a form object, rather than relying on Active Record internals for doing this.
    1. # Returns a new relation, which is the logical union of this relation and the one passed as an # argument. # # The two relations must be structurally compatible: they must be scoping the same model, and # they must differ only by #where (if no #group has been defined) or #having (if a #group is # present). Neither relation may have a #limit, #offset, or #distinct set.
  15. Jul 2020
    1. [:returning] (Postgres-only) An array of attributes that should be returned for all successfully inserted records. For databases that support INSERT ... RETURNING, this will default to returning the primary keys of the successfully inserted records. Pass returning: %w[ id name ] to return the id and name of every successfully inserted record or pass returning: false to omit the clause.
  16. Jun 2020
    1. If those comments are loaded outside of the blog_post association, then attempting to reference the blog_post association from within each comment will result in N blog_posts table queries even if they all belong to the same BlogPost!
    1. In this case, we notice that comment.post and post should belong to the same database object. But, is Rails smart enough to know that the comment should be removed from both of the associations? Or are comment.post and post different representations of the same database row?
    1. transaction calls can be nested. By default, this makes all database statements in the nested transaction block become part of the parent transaction. For example, the following behavior may be surprising: User.transaction do User.create(username: 'Kotori') User.transaction do User.create(username: 'Nemu') raise ActiveRecord::Rollback end end creates both “Kotori” and “Nemu”. Reason is the ActiveRecord::Rollback exception in the nested block does not issue a ROLLBACK. Since these exceptions are captured in transaction blocks, the parent block does not see it and the real transaction is committed.

      How is this okay??

      When would it ever be the desired/intended behavior for a raise ActiveRecord::Rollback to have absolutely no effect? What good is the transaction then??

      What happened to the principle of least surprise?

      Is there any reason we shouldn't just always use requires_new: true?

      If, like they say, the inner transaction "become[s] part of the parent transaction", then if anything, it should roll back the parent transaction too — not roll back nothing.

    2. One workaround is to begin a transaction on each class whose models you alter:
  17. Apr 2020
  18. Jan 2020
    1. I love merge too. Wow, it's been around a while.

      > ? merge
      
      From: ~/.gem/ruby/2.4.5/gems/activerecord-5.2.2/lib/active_record/relation/spawn_methods.rb @ line 14:
      Owner: ActiveRecord::SpawnMethods
      Visibility: public
      Signature: merge(other)
      Number of lines: 17
      
      Merges in the conditions from other, if other is an ActiveRecord::Relation.
      Returns an array representing the intersection of the resulting records with other, if other is an array.
      
    1. table name was not specified in the default scope definition. Since ActiveRecord does not canonically reference fields, after inner joining with another table another_table.term_id column can’t be found.
    1. You might be thinking––"a tool that allows me to write semantic and reusable queries? Sounds like Active Record". It's absolutley true that Active Record already provides a powerful query tool kit. But what happens when even simple queries stretch the bounds of Active Record's capabilities?
    1. before_destroy callbacks should be placed before dependent: :destroy associations (or use the prepend: true option), to ensure they execute before the records are deleted by dependent: :destroy.
  19. Dec 2019
  20. Aug 2019