search

doctrine / KeyValueStore

Abstraction for Key-Value to Plain Old PHP Object mapping
http://www.doctrine-project.org
MIT License
200 stars 59 forks source link

OneToOne / OneToMany / ManyToOne / ManyToMany relationship support? #86

Closed k-vladyslav closed 7 years ago

k-vladyslav commented 7 years ago

@beberlei @EmanueleMinotto is there any plans to add OneToOne / OneToMany / ManyToOne / ManyToMany relationships support, like in Doctrine2 ORM http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/association-mapping.html ? I think it would be very handy to be able to use same entity class with several mappings (ORM and KeyValue) instead of creating multiple domain classes just for several storages with 90% similar structure. Because right now I don't see easy solution on how to use existed Entities (which has OneToSomething relationships and are persisted with Doctrine 2 ORM) in conjunction with this library.

Ocramius commented 7 years ago

That's... Not what a key-value storage is for. We'd be building the wrong abstraction around the wrong technology.

k-vladyslav commented 7 years ago

@Ocramius why? I don't see any issues with that approach. Redis, for example, is hell-fast, and I'd rather prefer to use it as a persistent storage for high-frequency changed data, instead of bumping MySQL/PGSQL/whatever-sql through Doctrine2. Lets consider classic Book-Author example with 1:* relationship - l don't want my domain-level layer to be involved into knowledge like "oh here we have entity class Book (SQL persisted) and entity class BookCache (KV persisted), then Author and AuthorCache (and 533 other invariants) so lets mess up with all that". Instead I need one single Book and Author entity class, which will be "storage-agnostic". Then they have all required mapping (annotations, yml, xml, whatever) for both SQL an KV persistence. Then client code will work with that objects in same way, no matter where do we save them after. Risk: I only have to handle "invalidation" routine for KV layer and use it mostly as a "view layer", so all updates should be done in pair with SQL insert/update operations. For KV storage (in my case) I think read:write ratio will be around 1000:1

If You not agree - give me Your use case of this library.

lcobucci commented 7 years ago

@k-vladyslav if speed is your ONLY concern, the ORM's L2C solves that issue without making people add unnecessary logic on their side and invalidation is handled as bonus.

If you really want to optimise things for reading, you should have a different model for that. In this case, your read models will have everything you need to display a resource (with a single query) and that basically invalidates your suggestion of adding associations. And that is a use for this library.

k-vladyslav commented 7 years ago

@lcobucci thanks, I think there is no better solution (nowadays) than L2C for me.

lcobucci commented 7 years ago

@k-vladyslav glad to know that I helped in someway. It's just important to mention that I didn't mean that you should create the same model for different storages, I was merely referring to things like CQRS where you have two different models: one optimised for writing and the other for reading (regardless on the way you store things). You could even go further and talk about event sourcing and stuff.

However, I think this goes WAY beyond this issue. Having that said, could we close it?

k-vladyslav commented 7 years ago

@lcobucci pretty much, thanks for time, I closed that.