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.

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}]}

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.

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.

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.

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.

where_values_hash.reduce(&:or)

scope :deck_access, ->(user) { includes(:deck_permissions).where(where({ deck_permissions: { user_id: user.id, read_access: true } }, global_deck_read: true, user_id: user.id).where_values_hash.reduce(&:or)) }

# 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.

[: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.

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!

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?

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.

One workaround is to begin a transaction on each class whose models you alter:

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.

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?

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.

Event.joins(:packages).having('array_agg(packages.type) @> array[?]', packages).group(:id)