Enable ActiveRecord unsigned integers to use 8 bytes instead of 4. This fixes the ActiveModel::RangeError problem where AR models with perfectly fine 8 bytes primary keys are taken for ActiveModel::Type::Integer with a default limit of 4 bytes.

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

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

class Project< ApplicationRecord belongs_to_many :employees end

add_column :videos, :tag_ids, :bigint, array: true Tag.has_many :videos, array: true

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

t.datetime :seen_at, default: { expr: 'NOW()' }

Define table structure (columns and indexes) inside your ActiveRecord models like you can do in migrations. Also similar to DataMapper inline schema syntax.

It's more opinionated than active_record_migrations and standalone-migrations, and therefore simpler to configure.

class Note < ApplicationRecord delegated_type :authorable, types: %w[ Customer Employee ] end

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,

composed_of attr, :class_name => 'AddressableRecord::Address', :converter => :convert, :allow_nil => true,

belongs_to :city

Country State (belongs to country) City (belongs to State) Neighborhood (belongs to city)

Address (Belongs to Neighborhood and City, because neighborhood is not required)

and calls .unarchived and .archived appropriately when passed an ActiveRecord relation.

index_errors: true

Is there a way to select from multiple custom tables using ActiveRecord QueryMethods? I'm trying to replicate this SQL query using Ruby's ActiveRecord Query Methods. select employee.emplid, address.location from (....) employee, (....) address where employee.emplid = address.emplid

ActiveRecord::Relation::QueryAttribute.new(nil, value, ActiveRecord::Type::Value.new)

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)