ActiveRecord Without a Database? Replacement for broken Class.new(ActiveRecord::Base). Very useful in testing Rails apps, and even more so for testing gems without having to specify full blown models. If you prefer an exceptionally hacky alternative that could also be used for real runtime code, see my other gem activerecord-tablefree! Installation Add this line to your application’s Gemfile: gem 'anonymous_active_record' And then execute: $ bundle Or install it yourself as: $ gem install anonymous_active_record Usage Require the library in your spec_helper or other test suite boot file.
ActiveRecord Without a Database? ActiveRecord Tablefree Models provides a simple mixin for creating models that are not bound to the database. This approach is useful for taking advantage of the features of ActiveRecord such as validation, relationships, nested_attributes, etc. This can also be very useful in testing where a mock-like object will suffice. This gem is exceptionally hacky. For an alternative solution, primarily aimed at testing, that is less hacky, see my other gem anonymous_active_record!
Properly Implement ActiveRecord Transactions Provides a method, transaction_wrapper at the class and instance levels that can be used instead of ActiveRecord#transaction. Enables you to do transactions properly, with custom rescues and retry, including with or without locking. Installation Add this line to your application’s Gemfile: gem 'activerecord-transactionable' And then execute: $ bundle Or install it yourself as: $ gem install activerecord-transactionable Usage class Car < ActiveRecord::Base include Activerecord::Transactionable # Note lowercase "r" in Activerecord (different namespace than rails' module) validates_presence_of :name end When creating, saving, deleting within the transaction make sure to use the bang methods (!
Why Should You Use flag_shih_tzu
What is it? See the what is it post. Why should you use it? No migrations needed for new boolean attributes Avoids ALTER TABLE when adding a new boolean field to a model, which can be important for very large tables Only the one integer column needs to be indexed The index is actually meaningful, unlike a boolean column index Bitwise operations are fast, indexes are even faster, and you can use either one Adds scopes to easily access collections of records with specific fields Chained scopes to combine sql for different bit fields for maximum performance Provides condition builder methods for each bit field so you can construct your own custom SQL with the correct bit field values for the list.
Performance Measured and Tuned Batch Processing of Records with Blocks in Rails. EachInBatches (Originally BolingForBatches) NOTE: I am resurrecting this code because I still have this recurring need, and Rail’s native batching doesn’t cut mustard. It is some of my most ancient code, and it isn’t pretty, but I hope to improve it over time. I often need to execute really large computations on really large data sets. I usually end up writing a rake task to do it, which calls methods in my models.
Collect errors from multiple objects on a single object, especially useful with the Form Object Presenter Pattern. I’ll put something here soon.
Organize data results from raw sql queries (as with PGresult, or Dossier) intelligently. I’ll put something here soon.
Bit Fields for Active Record What is a bit field? https://en.wikipedia.org/wiki/Bit_field What is a bitwise operation? https://en.wikipedia.org/wiki/Bitwise_operation flag_shih_tzu supports both :bit_operator and :in_list query modes, but only :in_list can will utilize a database index. What does it look like? class Lead < ActiveRecord::Base include FlagShihTzu has_flags 1 => :warm_up_email_sent, 2 => :follow_up_call_made, 3 => :final_email_sent, 4 => :appointment_scheduled, 5 => :not_interested, # You can specify use any integer column to use for flags!