Improve and extend mapper definition DSL about rom HOT 12 CLOSED

@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 moms 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.