Persistence pays off: a new look at rom-rb
summary
ROM 3.0 ships with a stable rom-sql adapter and rom-repository and rethinks persistence as composable objects and functional relations, combining relations repositories change sets to fetch, transform and persist application data. It reports small codebases—3,322 lines core, 2,102 lines SQL adapter, 1,080 lines repository (6,504 total)—and already powers integrations like Hanami and Trailblazer while adapters for HTTP, Dynamo and CouchDB exist in production or prototype, with ongoing work on performance, prepared statements and documentation.
AI-written summary · about
chapters (25)
- 0:00Intro
- 1:423. How does it differ from typical rubygems? 4. Future challenges and how you can help
- 2:21Why rom-rb was created?
- 2:39Problem separating persistence from domain layer
- 6:04Application data is the most important part of your system
- 7:44It should be easy to retrieve application data from the database
- 8:00It should be easy to store application data transformed to a format compatible with your database
- 8:41Data integrity is crucial to have a healthy application
- 8:57It is the database that provides the best mechanisms to ensure data integrity, not fancy Ruby validation DSL
- 9:54rom-rb was created to address these issues
- 10:06How does rom-rb work?
- 10:54Repositories encapsulate accessing application data
- 12:08Through a simple convention, we hide database-specific DSLs behind our repository interface
- 12:51Relations encapsulate database queries
- 16:17Let's add custom sorting
- 20:29What about changing data?
- 20:47Changesets simplify creating and updating data in your database
- 24:15How rom-rb is different?
- 24:27rom-rb is functional
- 26:04rom-rb is object-oriented
- 27:11Composable gems
- 28:14Gems built with composition and reusability in mind are a great win for our ecosystem L
- 30:02Reminder: composition inheritance !
- 30:22Real world examples!
- 34:06USE IT !
