Comments (12)
@snusnu psssst wdyt? :)
from rom.
@solnic Looks good to me. ramom
takes a slightly different approach (as you know) in that it only exposes relations (which means that only RA ops can be applied to them) and doesn't support chaining relations the way rom
does. As a consequence, all virtual relation mappers need to be defined explicitly (base relations mappers are inferred automatically) and need to be given unique names (just as with relations). Where rom
supports users.with_tasks
, ramom
supports exposing a users_with_tasks
relation which can be hooked up with e.g. a user_with_tasks
mapper. One thing ramom
(specifically mom
for that matter) is still missing, is a way to easily define virtual relation mappers without having to repeat attributes coming from respective base relations.
In relation to your DSL suggestion, this basically means that if I want a user
and a user_with_tasks
mapper, I currently have to list user
attributes in addition to doing group :tasks
in the user_with_tasks
mapper definition. This is something I've been wanting to enhance for some time now, and maybe I find the time to do so soonish. Your DSL suggestion seems to solve that by allowing
with_tasks do
group tasks: [:title, :priority]
end
For mom
, it seems that this would boil down to exposing wrap
/unwrap
and group
/ungroup
on mapper definitions.
from rom.
Yes I want explicit mapper definitions too. Even with chaining it is your job to provide mappers that will know how to load a specific relation.
I'm still trying to come up with an interface for reading relations with mappers. I remember we talked about a "reader" objects or an explicit "query" interface where you basically make it clear that you want to read a specific relation using a specific mapper. Do you have any thoughts on that?
from rom.
i'd encourage you to read ramom's code starting with the integration spec and having a look at what gets used. regarding the reader, here's what ramom uses: https://github.com/snusnu/ramom/blob/master/lib/ramom/reader.rb ... it's true that i expose db interactions with either queries or commands (which incidentally provide a nice place to link a relation to its respective mapper).
from rom.
i actually have quite a few local changes to ramom (mostly covering the commands tho, reading mostly stayed the same). it's a bit hard for me to push that stuff to github right now, for reasons best not explained here ;)
from rom.
@snusnu yeah exactly reader sounds like a great place for that. I also have another reason to do this separation (read/command) and it's because I'm not planning to add support for commands on top of in-memory relations (stuff produced by ROM::RA
ops). That's why I need a separate command interface which would only expose base relations.
from rom.
@solnic as a heads up, here's how i "link" relations and their mappers: https://github.com/snusnu/ramom/blob/master/spec/integration/schema_spec.rb#L268
from rom.
as a side note, wdyt about using mom for the mapper component (well, maybe in the longterm at least). In my experience, the actual mapping is completely decoupled from a lib like rom. Mappers don't need to know anything database related, something which mom
demonstrates nicely imo. ramom
makes use of mom
and extends it in a few places, but doing so needs no particular groundwork on mom
s side.
from rom.
@snusnu I'll resurrect rom-mapper at some point. I agree that it's a totally separate piece but for now it'll be part of rom as things are moving faster this way. I'm not sure if I want to make morpher the mapping backend, it can be an overkill in many cases.
from rom.
@snusnu here's what I ended up with:
rom.relations do
users do
def with_tasks
RA.group(natural_join(tasks), tasks: [:title, :priority])
end
def sorted
order(:name)
end
end
end
rom.mappers do
users do
model name: 'User'
with_tasks do
model name: 'UserWithTasks', map: [:name, :email, :tasks]
group tasks: [:title, :priority]
end
end
end
Notice that by default ROM would build anonymous entity classes but you can provide :name
and a constant will be defined for you.
from rom.
The only thing which completely sucks right now is how headers are being handled. I'm going to make it possible to simply ask a relation for its header. For now only base relations return correct headers but if you apply a RA operation on top of base relations then the header no longer reflects the actual state. It's a simple thing to improve though so I'm not overly worried ;)
from rom.
The foundation for this is done and it's good enough so I'm closing this one. I'll add more detailed issues about specific features and enhancements.
from rom.
Related Issues (20)
- AutoStruct does not respect type definition when creating HOT 9
- Relation with name `:schema' causes registration problems
- Relax freezing policy for `ROM::Configurable`
- Using Repository#transaction with non-default gateways HOT 2
- Fix Ruby 3.0 compatibility HOT 3
- Running tests raises 'Too many open files - getcwd (Errno::EMFILE)' HOT 1
- Inconsistency between Time formats in ROM::Changeset::PipeRegistry and ROM::Plugins::Command::Timestamps HOT 1
- Relation doesn't work in repository HOT 2
- delete: :by_pk in a repository breaks with timestamps plugin
- Associated entities are not mapped to their entity-classes in case of alias HOT 3
- Error when a relation with the name `options` exists. HOT 2
- Unable to modify the node of a combined assc. when a child of that assc. is combined.
- Aggregate write on self referencing relation not setting foreign key HOT 1
- Batch insert with one INSERT query HOT 7
- Fix multiple association block use to prevent ROM::AssociationSet registry error HOT 1
- Rails 7.1 incompatibility (Object#with) HOT 5
- Broken example code, unexpected auto_struct behavior HOT 3
- uninitialized constant ROM::Memory::Types::Int HOT 3
- Rails 7.1 Upgrade Causes map_with To Throw ArgumentError HOT 3
- Excessive memory use with many relations (>500) HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rom.