I have an Events relation that defines a schema. I’ve configured it to use the Event struct, which inherits from ROM::Struct. How can I instantiate a new Event instance and then use the create command to insert new records into my dataset? Do I have to define the attributes on the custom struct? What if I’m trying to take advantage of the infer: true option?
Thanks.
How can I instantiate a new Event instance and then use the create command to insert new records into my dataset?
You can get the struct class via relation.mapper.model, but I would recommend to use plain hashes with commands/changesets.
Do I have to define the attributes on the custom struct?
No, the whole point of auto-structs is to avoid having to define attributes manually.
What if I’m trying to take advantage of the infer: true option?
infer: true is for relation schemas, are we talking about rom-sql here?
Hi @solnic,
Yeah, this is in the context of rom-sql. I was having trouble getting the infer: true to load the schema to then coerce data. However, I’ve worked around that issue by explicitly defining the schema in the relation. Furthermore, this is also in the context of getting a test suite working, in terms of getting this to all work together.
I’ve been creating a rom-sql adapter for the RailsEventStore project to use their Event Sourcing model with ROM. This has been my first use of ROM to learn the framework. I have many more questions, but this project will provide some context for how I’ve got things to work: https://github.com/RailsEventStore/rails_event_store/tree/master/ruby_event_store_rom_sql
I just recently was trying to figure out how to specify a default mapper on a repository or a relation. Is that possible? The goal is to use the mapper to map entities to a custom class, but it seems I have to call map_with in each repository method before returning a result?
Thanks for the help!
~Joel
@solnic I want to make one more note that my goal is to refactor the RailsEventStore ROM adapter to make the relation classes implement an interface that the repository classes use, so that the backing store can be interchangeable. I’m interested in your thoughts or direction on that, to allow ROM to be utilized as a way to make backing stores more pluggable.
Thanks.
I’m interested in your thoughts or direction on that, to allow ROM to be utilized as a way to make backing stores more pluggable.
Yes you can use ROM to achieve that. All you need is a common relation abstraction that is implemented by all your relations, regardless of the backend. Then the repo doesn’t care which relations it uses, because the relation API is the same. You can then initialize this repo using different rom containers, where each container can provide different backends.
@solnic yep! That’s the idea. There are some methods I’d assume might be built-in to the relation by default - are there any plans to expand the default methods, or is it not meant to provide a “standard” interface with broader capabilities?
Specifically, limit to limit the number of records returned or an “offset” as well seemed like a natural built-in… maybe even ability to specify a range like relation[3..7] to specify an offset.
Next, I’m going to be working with Session to use the transaction abstraction and see how that goes…