[Cubicweb] Status of the container cube
aurelien.campeas at logilab.fr
Fri Feb 28 16:02:11 CET 2014
The container cube is knowing no end of patches, and this is a good
thing. It recently got new "users" and each of these new users come
with their own fancy ways of using, and even, combining containers,
which is quite pleasing.
Container 2.3.0 was just published. This release was mainly concerned
with raw performance of the cloning operation.
Now that this round of performance patches is behind us, we need to
concentrate on the next batch of patches, most of which seem to
revolve around ease of use, basic apis and some operation semantics.
As of today, container is more like a toolkit from which people will
assemble things than a plug-and-forget thing.
Setting up a container is complicated, but I initially wanted to wait
on the upcoming custom yams "annotations" to de-complicate it and
actually automate most of the setup.
However, we have contributions right now that propose a configuration
object to simplify the setup (because waiting for yams annotations
looks like too long a wait).
This is a good thing and I see good ideas in the proposed patches. It
seems to come at the price of a deprecation of current apis.
But I also planned some important changes in the 3.0 version which,
you guessed, also entail deep api changes.
I herein propose to review the relevant tickets. In first position, I
put Denis' "important" tickets, then mine.
*disclaimer* this may be a ong read but I find useful to regroup
things here this way */disclaimer*
* https://www.cubicweb.org/ticket/3564655 aka "CONFIGURATION"
provide a mechanism to simplify setup
Currently, container configuration is probably the main difficulty
on the road to using the cube's functionalities.
One has to declare the configuration in several different places
(schema, entities, hooks).
Apart from these declarations, the setup consists of either adding
callbacks (e.g. in schema.py), defining entity classes, adapters,
setting adapters/hooks selectors. When security comes into play, it
adds an extra layer of complexity.
So this ticket is an effort to improve the current situation.
The main idea is add a unique configuration entry point, namely a
class which methods would be called in schema/entities/hooks
* https://www.cubicweb.org/ticket/3552734 aka "SUBGRAPH LINK"
rebuild container relation for top-less containers
Followup for https://www.cubicweb.org/ticket/3488993.
Now that we're able to build top-less containers (i.e. a subgraph of
a container, with no container entity), it'd be nice if the
container relation could be handled when the top-less container are
later attached to the container.
Currently, the relation to the container is only added for the head
entity of the top-less container, but not for its children.
* https://www.cubicweb.org/ticket/3595279 aka "ENTITY HOOKS+CLONE"
compulsory_hooks_categories does not work
As far as I can see, setting this attribute in the clone adapter
does not enable specified hooks categories.
E.g. I'm trying to set compulsory_hooks_categories=('workflow', )
but none of the workflow hooks are actually triggered during
Tests are missing for this feature.
* https://www.cubicweb.org/ticket/3589525 aka "METATADA UPDATE"
owned_by relation is not set for container entities during clone
Currently, entities created upon cloning of a container do not have
anything in their owned_by relation.
* https://www.cubicweb.org/ticket/3547361 aka "BORDER PERMISSIONS"
permissions on 'border-crossing' composite relation are not
Consider a border crossing relation composite in an entity type not
in container scope. The current implementation of
rdefs_roles_to_container (in setup_container_rtypes_security) will
find that the so-called "role to container" is the composite, which
is not in the scope of the container. So the resulting rql
expression will never apply.
It seems to me that considering the compositiness here is a bit
arbitrary, and it does not work in this case.
There are a handful other tickets but I believe these are less
important or essential in the very short term.
* https://www.cubicweb.org/ticket/3589827 aka "SWITCH TO RDEFS"
use plain rdefs everywhere
This is an old nagging design flaw: we use etypes and rtypes sets to
shape the container.
When people start playing with rtypes that have rdefs in the
container, at the border, or in outer space, things fall a bit
* https://www.cubicweb.org/ticket/3084215 aka "REFLEXIVE CONTAINER_RTYPE"
make the <container> relation reflexive
That would avoid nasty (and growing) special cases in some parts of
the code (e.g. the security weaver, cloning).
* https://www.cubicweb.org/ticket/2557494 aka "CONTAINER_ROOT"
replace <container_rtype> with container_root, wipe container_etype
This is a potentially important simplification. I would love current
container users try to bring their perspective on this.
potential flexibility loss (e.g. having entities really hosted
by two containers at the _same time_, which I'm not convinced
is a direction we want to take)
applications will have to be (slightly) adapted
imaginary (contorted) use case: en etype in C1 and C2:
__unique_together__ = [(name, rel_to_c1_root)]
Which says Babar name must be unique when in C1 (but nothing
special when in C2)
container_root is now 100% automatic, drops from the
simpler, easier-to-grasp conceptual model
consumes less space for entities potentially hosted by several
Now, I would like to address some of Denis' tickets.
* SUBGRAPH LINK: the use case is very new (to me at least) and the patch
appears not to be mature enough for short term integration. I suspect
the patch could live for a while in the "client" cube until this is
* ENTITY HOOKS+CLONE: the clone is currently defined as the identity
transform (plus some -still incomplete- api to modify things).
The recent optimisation pass has had the side-effect to render
inoperant any explicitly allowed entity hook while the clone is
While I agree that having a complete "transform" api (rather than
carbon copy) is desirable, it is not there yet and should not be
The exact use case for this ticket is resetting cloned entities to
their inital workflow state. This can be done currently in a
post-processing step just after the clone.
* METATADA UPDATE is a variant of the above. Since the clone operation
performs a strict copy, relations such as owned_by (or other cubicweb
metadata relations/attributes) are set to their original values.
This can be seen as going counter standard intuitions. Providing
rope to ensure classic metadata is "up-to-date" after a clone is a
good idea and must be done. In a major revision (e.g. 3 or 4) of
container, it is also possible that we switch from the current
default (pure carbon copy) to another "more intuitive" (and aligned
with CubicWeb semantics for metadata) default, where standard
metadata are updated (unless explicitely deactivated).
* BORDER PERMISSIONS: this is admittedly uncharted territory. I still
don't know what we should do in the generic case. I suspect this
will be heavily application/policy dependant. We need to learn more
before jumping to enhancements imho.
I think all the underlying issue are valid, but may not be addressed
immediately, for lack of a clear understanding of the implications.
Also because the time is short and we must try to build a maximally
useful next version within a very short timeframe.
Which means we should concentrate on the CONFIGURATION issue. The
details of the proposal really lie in the proposed patches, though the
principles are agreeable:
* a central container configuration object
* regrouping most of the functions currently sitting in container.utils
* bringing a good deal of simplification of a container setup
But with this proposal we get a deprecation of the current apis.
Also, of my own proposal, there are two I believe are fundamental
(they are original design flaws of container) and should be done asap:
SWITCH TO RDEFS and REFLEXIVE CONTAINER_RTYPE.
These also entail a complete api change, especially SWITCH TO RDEFS.
Now let's discuss.
First, If you disagree with the way I present or prioritize things,
please tell so.
If you agree that the most important things are CONFIGURATION (and
possibly SWITCH TO RDEFS), then I will have a sprint the whole of
monday-tuesday because after that I'm supposed to be on vacation, but
collaboration and Simulagora -at least- want something very fast).
This might be doable but it looks actually risky.
A second possibility is to put CONFIGURATION in container 2.4, and
then re-deprecate the API again for SWITCH-TO-RDEFS in 3.0. But I
would like to avoid this if possible.
Another possibility is to defer CONFIGURATION/container 3.0, rather
put CONFIGURATION into the collaboration cube, let it be used and
tested a bit, and then do it properly just after SWITCH-TO-RDEFS.
This is my preferred option as of today.
More information about the Cubicweb