The ORM::ActiveRecord adapter
ORM::Factory ships with a concrete adapter for
ORM::ActiveRecord. It is
auto-detected on first use: if ORM::ActiveRecord::Model is loadable in the
process, the AR adapter is registered, otherwise ORM::Factory falls back to
the generic adapter.
What the adapter wires up
ORM::Factory::Persistence::ActiveRecord implements the protocol from
Persistence on top of the AR model API:
instantiatecallsModel.build(%attrs), returning an unsaved instance withis-new-record === True.persistcalls.save-bang, so validation failures raiseX::RecordInvalidfromORM::ActiveRecord.is-valid/errorsdelegate to the model's own validation pipeline.primary-keyreturns the model's primary key (idby default).stubfakes a positive id and populatescreated_at/updated_atwithout hitting the database — seebuild-stubbedbelow.
build
ORM::Factory.build('user') returns an AR model with the attributes set but
no INSERT issued:
1 2 3 4 | |
create
ORM::Factory.create('user') runs the same pipeline as build, then calls
save-bang through the adapter. Model validations, callbacks, and
timestamps all run as usual:
1 2 3 4 5 | |
If validation fails, create raises the AR exception unchanged:
1 2 3 4 5 6 7 8 | |
build-stubbed
build-stubbed returns a model that looks persisted but never touched the
database:
1 2 3 4 5 6 7 | |
Use it for tests that need a record with associations and timestamps but do
not exercise the persistence path. Each stub gets a unique id from a process
counter; call
ORM::Factory::Persistence::ActiveRecord.new.reset-stub-counter between
suites if you want stable ids.
attributes-for
attributes-for bypasses the adapter entirely (see Persistence),
so it works identically whether AR is loaded or not.
Auto-detection
Detection is lazy and happens on first read of ORM::Factory.persistence. The
resolution order is:
- an adapter explicitly set via
ORM::Factory.set-persistence; ORM::Factory::Persistence::ActiveRecord, ifORM::ActiveRecord::Modelloads;ORM::Factory::Persistence::Generic.
The result is cached for the rest of the process. Use
ORM::Factory.reset-persistence (typically in test setup) to force a
re-detection.
1 2 3 4 | |
Test-suite cleanup
For tests, ORM::Factory::Cleanup exposes two strategies that target the AR
adapter directly:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | |
with-transaction-rollback is the lighter-weight option for fast specs; use
truncate-tables when the test cannot wrap itself in a single transaction
(e.g. specs that themselves open a transaction).
What the adapter does not do
The AR adapter targets the persistence protocol and nothing more. Anything specific to the model — validations, callbacks, association metadata, timestamps — is the model's responsibility. The adapter just forwards build / save / validate calls and fakes ids for stubs.