TBD: Orm-odm integration

[gonzalovilaseca]

As discussed here ir the first PR to start discussion.

[malukenho]

:+1:

[ElectricMaxxx]

i would not say "orm" and "odm" at all, cause this would mean to have two special managers of two doctrines (in the former doctrine view). So i would suggest a way to bekome more de-coupled like: a way to connect Object. That said it should be irrelevant if on object is an entity in the doctrine-orm view or a document from doctrine-phpcr, doctrine-mongodb ... or even the same.

[malukenho]

@ElectricMaxxx I think orm and odm is really relevant as a concept of this domain.

[ElectricMaxxx]

@malukenho but you would depend on implementations again. To avoid that should be a major Task of this library. Yea i know: it would be a short term goal to have a library that is able to reference some kind of document to an entity (or back). But i think we should think in long term goals for this library.

[malukenho]

@ElectricMaxxx I think I understand your point.

I think a way to connect Object not express what really we want here. a way to connect Object can be a PDO connection or a mysql_connect resource, and the orm is a OBLÍQUOS LANGUAGE to describe exactly what we want. A orm is a concept well defined.

[Ocramius]

Just a heads up on the current architecture I thought out:

• there is a concept of "loaders" in ChangeSet (not yet written down), and each loader is specific to one storage type
• each object type is configured with a specific loader. A "front loader" decides which loader to use for a specific requested type
• Entities are fetched via $loader->find($type, $identifier, $unitOfWork) (note that the UoW is passed in, as it is not a dependency anymore)

This sort of approach allows for:

• cross-db references
• avoiding UoW state leakage across multiple transactions (just build a new UoW each time)
• allows loaders to decide when to refresh objects or not
• is persistence agnostic

What is missing is some sort of "reference building", and I think $loader->getReference($type, $identifier, $unitOfWork) would cut it here.

Can the context be rewritten with this concept of "loaders" in mind?

[gonzalovilaseca]

Can you explain further the concept of "reference building", please?

[Ocramius]

@gonzalovilaseca reference building is the "lazy proxy" stuff that we have ;-) Getting an object, but not reading from the DB (yet)

[gonzalovilaseca]

@Ocramius Ok, I see, thanks. Are you sure we should rewrite the scenarios with the 'loaders' concept? Isn't that an implementation detail, not a behavior?

[Ocramius]

@gonzalovilaseca it's the actual terminology that I want to use in future. Not sure if there is a better naming, but I didn't have nor currently have time to inspect that further

[gonzalovilaseca]

@Ocramius Ok, I see no problem in using that terminology in the implementation. So if the behaviour described in the feature file looks ok, how/where can I start working on implementing it?

[Ocramius]

Start from writing down the feature context and then writing a PoC that just works with it. No interfaces needed.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 16 March 2015 at 10:36, Gonzalo Vilaseca notifications@github.com wrote:

@Ocramius https://github.com/Ocramius Ok, I see no problem in using that terminology in the implementation. So if the behaviour described in the feature file looks ok, how/where can I start working on implementing it?

— Reply to this email directly or view it on GitHub https://github.com/Ocramius/ChangeSet/pull/28#issuecomment-81569937.