ES CR Sync 7.1. (from memory)
(Sebastian, Robert, Bastian)
- Recap
- Decision & Kickstart: Try to run the docs.neos.io site on the ES CR! (#127)
ES CR Sync 11.1. (from memory)
(Sebastian, Bastian)
- Sebastian was very busy and pushed 23 Commits to fix incompatibilities with the docs site
- Remaining issues (currently):
- Caches are not flushed properly
-
idea: callback mechanism to hook into before and after ContentGraph projector transactions so that we can trigger the cache flusher during projection time (via JobQueue!)
-
related: The GraphProjector should be a class in the ESCR package using a new interface for the actual read model interaction (this will allow us to implement (and potentially refactor) core features like
GraphProjector::hasProcessed() and the hook mechanism mentioned before in a single place)
- FE search
- BE search
-
Flowpack.NodeTemplates package needs manual work
- probably some more
ES CR Sync 14.1.
(Sebastian, Christian, Viktor, Bastian)
BE Search is not working yet (#204)
Problem: The NodeSearchService needs a custom implementation. Unfortunately it currently has some quirks:
- the
$startingPoint argument (which is not part of the NodeSearchServiceInterface!) is actively used and makes this implementation complex/slow with the ESCR
- the return type is an array of
NodeInterface instances but effectively it is indexed by the corresponding node path
Idea: For a v1 Bastian will try to implement the interface with a custom (DBAL-based) projection and couple of limitations:
- The
$startingPoint argument won’t be supported (if it’s specified an exception will be thrown(?))
- The result will be limited to 15 nodes (reason: we’ll need to interact with the ContentGraph in order to get the node path and this is a rather slow operation)
For the final version we’ll probably need a new interface along the lines of SomeClass::someMethod(SearchTerm $term, NodeTypeConstraints $filter, ContentStreamIdentifier $contentStreamId, DimensionSpacePoint $dimensionSpacePoint): Nodes. (note: We might get around the startingPoint-requirement by using a CR per site, see below).
Publish button does not turn yellow for deleted/disabled nodes (#89)
Problem: The ContentGraph does not keep track of deleted nodes and a custom projection won’t know the affected document node of a deleted content node (unless it keeps track of the full node hierarchy)
Ideas:
- We could implement some kind of “DeletionEdge” (similar to the VisibilityEdges)
- For now we decided to add the
parentNodeAggregateIdentifier to the payload of the NodeAggregateWasRemoved event – but that probably won’t be enough for detecting deletions in deeply nested content nodes…
We agree that the state of the Publish Button is closely related to the feature of diffing two content streams (e.g. like we gonna need it for a revamped Workspace Module)
Multi Sites (or: Multiple CR instances) (#100)
We seem to come back to the issue of a “site context” and all the challenges that come with it
Ideas:
- Allow multiple ContentRepository instances to be instantiated in parallel
- In Neos a middleware could detect the correct “default” instance based on the current request
- [IMO] This CR instance would be the major API for all core interactions, i.e. act as command bus factory for Content(Sub)Graph instances and other core read models and allow for registering custom event listeners (if we go that route we won’t have a global event store but one per CR instance, so we can’t have global event listeners either)
// retrieve an instance by request (for Neos)
$neosCR = $this->neosContentRepositoryFactory->createFromRequest($serverRequest);
// dispatch commands
$neosCR->handle(new CreateNodeVariant(...));
// query nodes
$neosCr->contentGraph()->findNodeAggregateByIdentifier(...)
// instantiate custom instances
$tagsCR = $this->contentRepositoryFactory->get('My.Package:Tags');
$tagsCR->handle(new SetNodeProperties(...));
The next “ESCR Talk” will take place on Thursday, January 20th at 9.30am CET (!), feel free to join us in the #project-cr-rewrite Slack Channel
