Create persisters/map classes to cleanup the UoW

[ElectricMaxxx]

As the result of #493 we came to the conclusion to do some cleanup inside of the UoW. First step would be to move all code that handles the session to a so called persister as the ORM still does. I know that the session is a kind of a persister abstraction but not the same.
I still struggle with two thinks:

• how many code around those typical $this->session->getNode() should go into that new classes
• how to inject the array that contains the documents like scheduledForUpdate, identityMap, ...

I will have a longer train drive on sunday to create a plan for the first issue.

Even if i know that the UnitOfWork's main task is to create a communication between those arrays and the persistence layer, i would like to suggest to create some mini-container, like little UnitOfWork with common entries and a common interface like:

interface ScheduledContainerInterface
{
  public function register(ScheduledItemInterface $item);

  public function unregister(ScheduledItemInterface $item);

  public function getByIdentifier($id);

  ...
}

We would be able create a ScheduledForUpdates class with that interface and are able to inject it into an UpdatePersister for example:

$this->getPersister('update')->execute($this->scheduledForUpdates);

I do not really know if that would have some performance issues, but we would get a clear way of injecting scheduled/mapped objects into the persister. We will be able to handle the id<->uuid questions inside those classes tool.

[ElectricMaxxx]

I found some time to have a deeper look into the UoW. And i figures out, that the session is a persister as used in the ORM. It encapsulates all implementation depending stuff.
That session is called 31 times across the UoW only. (getNode() 14x, getWorkspace() 6x, refresh() 2x, save() 1x, move() 1x, getRepository() 1x, getSessionOption() 1x). That works perferkt as we serve the node's ids to the methods they need it.

So the messy part isn't the communication to the session (= our persister).

So we should do have a deeper look into the storing stuff into the intentityMap, scheduledFor* ... to serve the node's id in every situation.

[ElectricMaxxx]

Btw. i just had a quick talk with derick rethans about referencing documents. And he said i need to get rid of my thinking to reference documents by it's uuid. A document should be available by every identifier i have planed to be one. It's a kind of creating a schema for documents.

[dbu]

so you propose that instead of a simple array for the maps, we would use a more sophisticated class? not sure of the performance impact, but i guess its not much worse than calling functions inside the uow to interact with multiple arrays, and a lot cleaner.

[ElectricMaxxx]

It is no decision against a persister. But when you compare the ORM and the PHPCR UoW you will see that our session does exact the same as the calls on several persister does in the ORM.

The most other code is the handling with the maps (identity, scheduleFor*, ..) with the problem to fetch the right object from the right map with the right identifier.

[ElectricMaxxx]

Btw. I did the same "mistake" at my little UoW on the Bridge i wrote and now at the end of the day i got same issues.

My idea would be to create some interfaces, try it here and suggest the idea to the common doctrine.

[dbu]

i think doctrine orm 3 did a lot of cleanup. we could look into adapting more of its architecture, maybe there is useful code that moved to doctrine commons or other shared libraries.