A more powerful mapper for Lotus::Model

questions
1

From what I see, Lotus::Model mapping is limited to mapping simple tuple attributes to simple object attributes.

I’ve played around with ROM for while, its mapping functionallity is VERY powerful, it can perform all types of transformations on the data before building the entity or value object, it can even map a single tuple, to a complex aggregate of objects, or use various steps to map.

You can check various examples at ROM’s mappers guide.

This is very useful for getting the same data in different formats according to the context, and I miss it when using Lotus::Model.

What do you guys think about this?

ROM itself is very powerful and has various other interesting ideas we should look into, another example is ROM structs, returned from repositories.

And, could be relevant, ROM also uses Sequel as their SQL adapter and are build a Gem to integrate with Lotus.

2

Thanks for bringing this up. I might be biased by I think it’s a good idea to at least try using rom-mapper as the backend of lotus-model :wink:

I’m not sure what the plans for lotus-model are in terms of more complex features like dealing with associations and mapping to aggregates so it’s hard for me to tell if ROM could be useful for that part too. It’s been a long road to get where we are now with ROM so I’m really curious to know how lotus-model API is meant to look like.

From my experience manual mapping configuration is extremely tedious that’s why I built rom-repository with auto-mapping. I believe it’s the only good strategy for mapping to POROs. I would love to know how this is going to be handled in lotus-model. From what I’ve seen it has an explicit mapping configuration layer, similar to ROM’s mapper DSL. But without support for associations/aggregates it’s hard to tell how this will evolve.

2 Likes
3

@solnic, have you used rom inside lotus ? If so, what parts of rom works great and what parts are not so good to use today ? Could you talk a little more about your experience using rom with lotus ?

4

Interesting. I guess @solnic is the one who can best tell if ROM would be a fit for lotus.
Associations are being discussed and i played around with improving the mapper/coercer stuff.

5

Did not know ROM so i took a cursory read of the guides.

  • It looks like you need to explicitly extend a ROM class?
  • In lotus models are just PORO, no access to a datastore, only Repositories access DB. I don’t yet fully understand how/where access is done in ROM?
6

No, I haven’t got a chance to actually use Lotus with ROM. I only built a simple integration gem rom-lotus so that it’s easier to configure ROM inside a lotus app.

Integration with lotus is minimalistic, so there’s not much to write about to be honest. It only allows you to configure ROM gateways and the gem will load your components during booting so that the ROM container will be available to you.

Not really :smile: I can only say that ROM is way ahead of lotus-model and it’s completely different. As I mentioned I don’t know what the plans for lotus-model are so can’t compare the two properly. Since Lotus is not built with any specific persistence library in mind I bet it should be easy to use ROM inside a lotus app.

Please feel free to ask me some specific questions, I’m happy to reply, I could give you a lot of insights but I’d prefer to answer specific questions instead :smile:

7

Relations, commands and repositories do inherit from core ROM classes…

[quote]In lotus models are just PORO, no access to a datastore, only Repositories access DB. I don’t yet fully understand how/where access is done in ROM?
[/quote]

…ROM is a toolkit and it’s based on a layered architecture. There are no abstract query interfaces for all adapters, adapters are minimalistic so that you can leverage your db features using lower level query DSLs and various db-driver-specific features (if needed), there’s adapter gateway layer with lower-level APIs for talking to databases, there’s data-access layer known as relations, there are mappers for transforming data to domain-specific structures, and finally we have a repository layer for simplified data access. ROM also ships with a command layer for create/update/delete operations (or in general data manipulation APIs) which adheres to the CQRS architecture.

So, relations inherit from core gateway classes, but the data is turned into PORO, in fact, you can map to whatever you want. ROM Mapper is extremely powerful and extendible.

8

@solnic, thanks for the explanations.

So ROM could fit into Lotus in that it would replace the repository/collection part of lotus?

Not that i have a say in this…:slight_smile:

9

Personally I’m not interested in mutable entities and having an abstraction where “I persist an entity” so that part of ROM doesn’t exist; however, many people would like to use it like that so we’re going to add it as it’s not going to complicate anything, it’s just an addition. This means that current functionality of ROM cannot replace lotus-model, yet.

I’m pretty sure rom-mapper or maybe even lower level transproc could be used by mapper part of lotus-model, this way we’d have less duplicated efforts.

You could replace lotus-model with ROM if we decided to cooperate and realize that indeed this comes with mutual benefits. Duplicated effort is not a bad thing when at the same time there’s many more differences, and maybe the two projects still differ too much that it makes no sense to use ROM instead of lotus-model simply because of those differences.

I’m open to discuss this of course, even when you still want an object-relational mapper you can have it on top of ROM, so there are plenty of possibilities here.

10

As said, this is not something i have a say in. Luca is the one to discuss this with.
To me it sounds like ROM might be something that can be used under the hood. But still a bit unsure how it would look like.
I’ve seen your talk in BCN some weeks ago. So i know you don’t like mutable entites:-)

11

@solnic thanks for the answers. I´ve implemented lotus+rom to experiment both projects and my conclusion is that lotus-model would fit as an high level abstraction of ROM (Lotus > Lotus-model > ROM > Sequel). Maybe that´s not the plan, but lotus-model would benefit from ROM.

12

Good to know, FWIW I believe it’s true but definitely needs a lot of discussion. I’ve been trying to build ROM to be a toolkit so in theory you should be able to build a higher-level abstractions on top of it. rom-repository is already such abstraction but I’m stubborn and keep it simple and not going anywhere near object-relational mapping world :smile:

13

Hey there, this discussion is dense of inputs. Thank you all. :smile:

Before to write a line of code in Lotus::Model, I always waited for ROM to see where it was going. Having it as a powerful backend has always been on my mind.

@solnic Has a lot of experience from DM1, the DM2 attempt and building ROM in the last 3 (?) years. As result, ROM is more robust, well designed and powerful than Lotus::Model.

I defend only one merit of Lotus::Model: it’s convincing some devs to move away from AR. At least now, people can see the benefits of decoupling entities from repositories, without diverging too much from what they already know.

For the rest of the Community, the mental overhead to get to a point where we can ditch our ORMs, is still high, IMO. It requires time to communicate the value and educate devs to new solutions.

They demand for example apps, real world use cases, documentation that speaks their own jargon. This is something that both Lotus and ROM have to prioritize now.

On the technical side, there are a lot of improvements for Lotus::Model: fine grained mapping, aggregates, immutability, true OOP, raw data flows, CQRS, more flexibility.
These are structural changes, that will probably use ROM as a backend, but I still to understand and learn it myself.

But, as recently announced, we want to get to Lotus 1.0 in a few months. That’s what devs demand for, and we need more traction for the project. In the end, persistence it’s only a part of Lotus, our effort has always been split between all the components.

I have a lot of questions about ROM, that would love to ask to @solnic, is anyone interested in sessions where we discuss about these things?

3 Likes
14

of course I am :+1: hehe

15

Absolutely! Looking forward to this. :+1:

16

[quote=“jodosha, post:13, topic:140”]
@solnic Has a lot of experience from DM1, the DM2 attempt and building ROM in the last 3 (?) years.[/quote]

Hmmm, I believe it’s roughly 4 years already :smile:

Thank you, feels like we’re getting there indeed wrt overall design. New adapters and new use-cases are proving the design makes sense :smile:

That’s a fair argument. I completely underestimated the effort that’s required to explain all the new ideas that come with ROM. We’ve already seen people tripping on it and not being able to use ROM because of lack of proper resources that would teach them how to do it effectively. Truth is - it’s still a young project, practically speaking it’s not even 1 year old given that it was rewritten last year.

I can definitely see why being pragmatic here and providing something that won’t be too different may have a lot of value for people.

Yes exactly, that’s why I decided to write a book about it because documenting everything is too much work for now and I need to clearly communicate ideas behind ROM first with the hope that people will pick it up and help with documentation as a result.

I gotta be totally honest here - I don’t believe that building another ORM makes sense in the long term. I would definitely like to see ROM being used as a backend for some higher-level library because that would prove its flexibility and robustness; however, it would still require a lot of complexity to manage mutable state of domain objects, something I personally do not want to deal with anymore.

Moving people away from AR thanks to Lotus::Model is a great idea but I’m worried that in the longer term it simply won’t make much of a difference given the complexity that’s involved. A full-featured Data Mapper is a really complex beast.

The separation is great, you can always ship 1.0 of core components and continue working on lotus-model later.

Let’s do this :smile:

2 Likes
17

What do you mean? We are evaluating the idea to use ROM as backend for Lotus::Model as higher-level library. :wink: