Hierarchy statistics refinement about evitadb HOT 12 CLOSED

Refactoring of hierarchyParentsOfSelf and hierarchyParentsOfReference

The hierarchyParentsOfSelf has no sense now and will be removed without compensation.
The hierarchyParentsOfReference still has sense for scenarios where we want to access parents over entity references (for example for rendering breadcrumbs, or implement various decisions based on entity placement in the hierarchy tree). It will be removed in the form it has now, but it will by replaced by a new require constraint hierarchyContent, that might be optionally used inside referenceContent requirement in the following way:

referenceContent(
	Entities.CATEGORY,
	filterBy(entityPrimaryKeyInSet(randomCategories)),
	orderBy(
		entityProperty(
			attributeNatural(ATTRIBUTE_NAME, OrderDirection.DESC)
		)
	),
	entityFetch(attributeContent(), associatedDataContent()),
	hierarchyFetch()
)

When the hierarchyFetch is used, the new field parents in ReferenceDecorator will be filled with the parents of the referenced entity.

The new constraint optionally accepts entityFetch child that will trigger returning SealedEntity instead of EntityClassifier. Example:

referenceContent(
	Entities.CATEGORY,
	filterBy(entityPrimaryKeyInSet(randomCategories)),
	orderBy(
		entityProperty(
			attributeNatural(ATTRIBUTE_NAME, OrderDirection.DESC)
		)
	),
	entityFetch(attributeContent(), associatedDataContent()),
	hierarchyFetch(
		entityFetch(attributeContent(), associatedDataContent())
	)
)

The list of parents can be limited by using stopAt filtering constraint (so that only a single parent is sufficient to be returned):

referenceContent(
	Entities.CATEGORY,
	filterBy(entityPrimaryKeyInSet(randomCategories)),
	orderBy(
		entityProperty(
			attributeNatural(ATTRIBUTE_NAME, OrderDirection.DESC)
		)
	),
	entityFetch(attributeContent(), associatedDataContent()),
	hierarchyFetch(
		filterBy(
			stopAt(distance(1))
		),
		entityFetch(attributeContent(), associatedDataContent())
	)
)

from evitadb.

I don't want to make changes to the branch we want to stabilize in order ship changes for the frontend team, so I created new branch 7_dropping-hierary-parents-requirement where the HierarchyParentsOfSelf and HierarchyParentsOfReference are removed and HierarchyContent requirement added. No implementation is ready yet for the HierarchyContent.

from evitadb.

@lukashornych The constraints are prepared, tested and partly documented. I think it's ready to prepare:

• parser support
• GraphQL integration (with tests)
• REST integration (with tests)
• gRPC integration (with tests)

Meanwhile I implement the logic in the core.

from evitadb.

The core logic implemented. Now it's up to you @lukashornych - we need to propagate support to all APIs and correct 10 failing tests involved:

• gRPC API
• REST API
• GraphQL API

from evitadb.

Reopening automatic close - we have only core + GraphQL support. The gRPC and REST is still in front of us.
The GraphQL has there issues:

• internal constraints such as: stopAt, statistics should not start with keyword hierarchy
• the statistics enums should be added implicitly when the values they produce are required as fields of GQL query, the statistics constraint should be shortened in the GQL query because it now contains only the base enum

from evitadb.

The 2 todos mentioned in previous comment are merged in dev. Rest of the development will continue in #14.

from evitadb.

The functionality is completely prepared for API implementation. @lukashornych please look at the new form of hierarchyWithin constraint which now accepts multiple inner filtering constraints. I hope the composition will not be a problem for your constraint abstraction.

from evitadb.

The gRPC protocol implementation is updated.

from evitadb.

@lukashornych all constraints now target directly the referenced entity, no reference attributes are taken into an account.

from evitadb.

Now only the REST support is missing.

from evitadb.

REST API support is finished and merged in dev branch.

There is only one thing missing in EvitaQL: support for multiple reference names in hierarchyOfReference constraint, because there is varargs for these reference names followed by OPTIONAL enum value parameter. Problem occurs when we use positional or even named parameters from which we don't know beforehand if it will be classifier or value when parsing like so:

hierarchyOfReference(?, ?, ?, fromRoot())

which can be either

hierarchyOfReference('brand', 'category', LEAVE_EMPTY, fromRoot())

or

hierarchyOfReference('brand', 'category', 'parameter', fromRoot())

which currently I don't know how to solve.
If we add another branch into parser with only value varargs and parse it manually, we would have to remove current branches so that the parser is not confused or maybe use directly STRING literal instead of classifier. This would mean to duplicate all logic for classifiers to this one constraint, which IMO is a lot of custom manual DUPLICATE work for such edge case scenario.
We could add arrays into EvitaQL parser, this would solve cases where user uses EvitaQL directly, but wouldn't solve our Java Driver because the pretty printer on the backend will always print all arguments as varargs, it doesn't know about the inner arrays because Java constraint don't work with them either.

from evitadb.

Closing this issue. The only missing task is the EvitaQL parser support for multiple reference names which is not exactly problem with hierarchies. Therefore, we will solve this in smaller issue #155.

from evitadb.