Use ActiveModel::Attributes in Aws::Record
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start by tracing Aws::Record’s BaseModel attribute macros and the ModelAttributes and ItemData components named in the issue. Review how persisted fields, DynamoDB metadata, decorators, defaults, and dirty tracking currently interact. Done means ActiveModel decorators can observe every persisted field without breaking existing DynamoDB mapping and persistence behavior.
Written by the indexing model from the issue text.
Description
Describe the feature
Rework Aws::Record’s attribute layer so every attribute is registered through ActiveModel::Attributes. Under this approach, string_attr, integer_attr, etc. would become thin wrappers around attribute(name, type, default:), allowing decorators like ActiveModel::Attributes::Normalization#normalizes to hook into Aws::Record models.
Beyond normalization, this change would:
- Enable all current and future ActiveModel decorators (encryption, serialization helpers, etc.) on Aws::Record fields.
- Improve compatibility with form builders and other ActiveModel-based tools because casting, defaults, and dirty tracking come from the canonical Rails implementation.
- Reduce custom infrastructure—bug fixes and improvements in ActiveModel automatically flow to Aws::Record users instead of maintaining a parallel attribute system.
- Provide cleaner extension points: developers can register custom ActiveModel::Types or third-party decorators without fighting the DynamoDB marshaler layer.
- Simplify the codebase by letting ActiveModel::AttributeSet/ActiveModel::Dirty handle state tracking, trimming down ModelAttributes and ItemData.
Use Case
We attempted to use the new normalizes macro in our case for email addresses in an Aws::Record-backed app:
class Contact
include ActiveModel::Model
include ActiveModel::Attributes
include Aws::Record
include ActiveModel::Attributes::Normalization
string_attr :email
normalizes :email, with: -> value { value&.strip&.downcase }
end
That doesnt work.
Because every persisted field in BaseModel is declared with the Aws::Record macros (string_attr, integer_attr, etc.), the ActiveModel decorator hooks never see read/write operations, so normalization callbacks don’t fire. To make normalizes effective we’d have to redefine every attribute twice (attribute :foo for ActiveModel, plus string_attr :foo for Aws::Record) or build a bridge layer that makes Aws::Record emit the decorators ActiveModel expects. Both approaches would be fragile and risk the DynamoDB mapping getting out of sync. In short: adding include ActiveModel::Attributes to BaseModel won’t crash immediately, but it also doesn’t give us working normalization for the attributes we actually persist.
So we must maintain custom concerns instead of relying on the Rails-provided API.
Proposed Solution
Integrate ActiveModel::Attributes into Aws::Record’s core:
- Mix ActiveModel::Attributes into Aws::Record.
- Update attribute macros to call attribute(name, type, default:), wrapping existing DynamoDB marshalers in ActiveModel::Type subclasses.
- Preserve Dynamo-specific metadata (hash/range keys, GSIs, custom storage names) in side tables so persistence logic remains intact.
- Allow decorate_attributes to run on every field, unlocking normalization and other decorators.
- Refactor ModelAttributes/ItemData to lean on ActiveModel::AttributeSet and ActiveModel::Dirty for defaults and mutation tracking.
Prototype sketch:
class DynamoStringType < ActiveModel::Type::String
def serialize(value)
Aws::Record::Marshalers::StringMarshaler.new.serialize(value)
end
end
def string_attr(name, default: nil, **opts)
register_dynamo_metadata(name, opts)
attribute(name, DynamoStringType.new, default: default)
end
Other Information
No response
Acknowledgements
- I may be able to implement this feature request
- This feature might incur a breaking change
aws-sdk-ruby-record version used
latest
Environment details (OS name and version, etc.)
mac
- Dominant language
- Ruby
- Stars
- 318
- Forks
- 44
- Avg merge
- 9h 50m
- Merged PRs (30d)
- 2
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from aws/aws-record-ruby
-
bug p2
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
aws/aws-record-ruby#162 · 1 comment ·
-
BuildableSearch#complete!.to_a auto-paginates silently and Limit is per-page (companion to #153)Openfeature-request
Difficulty 5/5 Over a week Newbie friendliness 25/100
aws/aws-record-ruby#157 · 2 comments ·
-
feature-request
Difficulty 5/5 Over a week Newbie friendliness 38/100
aws/aws-record-ruby#155 · 1 comment ·
-
feature-request p2 queued
Difficulty 4/5 3-5 days Newbie friendliness 48/100
aws/aws-record-ruby#153 · 2 comments ·
-
feature-request
Difficulty 4/5 3-5 days Newbie friendliness 35/100
aws/aws-record-ruby#147 · 1 comment ·
All issues in aws/aws-record-ruby
Similar issues
-
security
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
ds-drift
Difficulty 1/5 Under an hour Newbie friendliness 88/100
we-promise/sure#3934 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 7 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
simp/pupmod-simp-ssh#246 ·