-
-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FEATURE: ContentGraphAdapter for write side access #4979
Conversation
Few notes here for starters:
|
Also I realized too late but why is e.g. the workspace projection in CR Core? it should be in the storage adapter implementations (so DBAL, postgres) etc. ? Same for the contentStreams... |
Is that related? |
More note.... I guess the adapter needs a bunch more dependencies to actually be able to provide Node(s) results, we'll see how that works out, they are obviously all available when building it, but I would rather want to avoid adding them... |
I tried to get rid of ALL access to finders within the handlers, so now I also took the worksapce and contentstream related methods into the adapter, which doesn't work because the DBAL adapter implementation then doesn't know about those :D |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks so much for your efforts!
I just did a first quick pass as preparation for our weekly.
Apart from the nitpicky comments, I think the adapter should always act on a workspace/contentstream
use Neos\ContentRepository\Core\SharedModel\Workspace\WorkspaceName; | ||
|
||
/** | ||
* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs some thorough documentation and an @internal
annotation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, documentation is missing everywhere just wanted to get this out here for now. Important though, so thanks!
// TODO: Implement rootNodeAggregateWithTypeExists() method. | ||
} | ||
|
||
public function findParentNodeAggregates(ContentStreamId $contentStreamId, WorkspaceName $workspaceName, NodeAggregateId $childNodeAggregateId): iterable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not directly related but we should really introduce a NodeAggregates
DTO
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, can do maybe
Neos.ContentGraph.DoctrineDbalAdapter/src/Domain/Repository/ContentGraphAdapterFactory.php
Outdated
Show resolved
Hide resolved
Neos.ContentRepository.Core/Classes/Feature/Common/ConstraintChecks.php
Outdated
Show resolved
Hide resolved
The write side no longer uses any regular finders for checks but only accesses projection data via the new `ContentGraphAdapterInterface`. Fixes: neos#4973
This also replaces the ContentStreamIdOverride
d0f89bd
to
c7480fe
Compare
Neos.ContentRepository.Core/Classes/Feature/ContentGraphAdapterInterface.php
Outdated
Show resolved
Hide resolved
Neos.ContentRepository.Core/Classes/Feature/ContentGraphAdapterInterface.php
Outdated
Show resolved
Hide resolved
Neos.ContentRepository.Core/Classes/Feature/ContentGraphAdapterInterface.php
Outdated
Show resolved
Hide resolved
Neos.ContentRepository.Core/Classes/Feature/ContentGraphAdapterInterface.php
Show resolved
Hide resolved
Adds the working DBAL implementation as well as some fixes. Also new Factory/Builder concept
All resolved for now, but I will probably poke a few other corners. Also now need to deduplicate the queries. |
* Builder to combine injected dependencies and ProjectionFActoryDependencies into a ContentGraphAdapterFactory | ||
* @internal | ||
*/ | ||
class ContentGraphAdapterFactoryBuilder implements ContentGraphAdapterFactoryBuilderInterface |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't mind getting around having this, and am happy for suggestions, I don't really see it though. An ugly option would be to to have something along the lines of:
ContentGraphAdapterFactory::injectProjectionDependencies(ProjectionFactoryDependencies $projectionFactoryDependencies)
and the ContentGraphAdapterFactory::__construct
just gets the adapter dependencies injected (eg. DBALClient), but then all methods in the ContentGraphAdapterFactory need to throw a "TooEarly" Exception if the projection dependencies were not injected yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIS we only need it to pass in ContentRepositoryId
, NodeTypeManager
and PropertyConverter
– Maybe we can make these explicit dependencies somehow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
..or even make the NodeFactory
an explicit dependency (via some NodeFactoryInterface
) but I don't know... Let's discuss
...TestSuite/Classes/Behavior/Features/Bootstrap/GenericCommandExecutionAndEventPublication.php
Outdated
Show resolved
Hide resolved
...TestSuite/Classes/Behavior/Features/Bootstrap/GenericCommandExecutionAndEventPublication.php
Outdated
Show resolved
Hide resolved
I think the idea is good, just where we create it and how we pass it along needs refinement, given that this PR will not stay as it is anyways, just putting it in to keep the idea intact.
In our weekly 2024-04-19 we talked about how this adapter is maybe not worth the trouble and if we can solve the ugly contentStreamIdOverride differently without this. And it is indeed difficult to make assumptions for after introduction of node identity, but it is very clear to me that at a higher level commands and API will use workspaceName the queries (at least for the DBAL Adapter) will need a contentStreamId to work, therefore this translation will have to happen somewhere, IMHO the changes for NodeIdentity will just push this deeper into the read side making it even more annoying (e.g. due to This together with the (from the POV of the write side) convoluted API to read stuff lets me think that this change could have merit even IF we cannot at this point avoid using read models (IMHO this could be a later improvement though) and much easier to just change the write side interface for this. Convoluted because we apply filters, visibility and a lot of other stuff. I am still not in love with the triple factory thing, but the separation of APIs seems very sensible still. |
'Neos.ContentRepository:ContentGraph': | ||
factoryObjectName: Neos\ContentGraph\DoctrineDbalAdapter\DoctrineDbalContentGraphProjectionFactory | ||
contentGraphAdapterFactory: | ||
factoryObjectName: Neos\ContentGraph\DoctrineDbalAdapter\ContentGraphAdapterFactoryBuilder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
optional followup would be to simplify this config
if (!$contentGraphAdapterFactoryBuilder instanceof ContentGraphAdapterFactoryBuilderInterface) { | ||
throw InvalidConfigurationException::fromMessage('contentGraphAdapterFactory.factoryObjectName for content repository "%s" is not an instance of %s but %s.', $contentRepositoryIdentifier->value, ContentGraphAdapterFactoryBuilderInterface::class, get_debug_type($contentGraphAdapterFactoryBuilder)); | ||
} | ||
// TODO: Do we want to add options here? Would then have to be a setter I guess.... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
todo over here ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should refine this naming
public function getWorkspace(): Workspace | ||
{ | ||
$query = $this->dbalConnection->prepare('SELECT * FROM cr_default_p_workspace WHERE workspacename LIKE :workspaceName'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
illegal select, and the Workspace
tdo is too big
// TODO: This table is not allowed here... | ||
$query = $this->dbalConnection->prepare('SELECT currentcontentstreamid FROM cr_default_p_workspace WHERE workspacename LIKE :workspaceName'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
todo illegal
This is to be replaced by #5028 and I suggest to close the PR (we can still keep the branch for reference if needed) |
The write side no longer uses any regular finders
for checks but only accesses projection data via
the new
ContentGraphAdapterInterface
.Fixes: #4973