[Cubicweb] Status of the container cube

Aurélien Campéas aurelien.campeas at logilab.fr
Fri Feb 28 16:02:11 CET 2014


Dear list,

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*


Denis'  tickets:


* 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
  callbacks.


* 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
  cloning.

  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
  correctly set

  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.



Aurelien's tickets:

* 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
  apart.


* 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.

    cons:

        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:

        class Babar(EntityType):
            __unique_together__ = [(name, rel_to_c1_root)]

        Which says Babar name must be unique when in C1 (but nothing
        special when in C2)

    pros:

        container_root is now 100% automatic, drops from the
        configuration

        simpler, easier-to-grasp conceptual model

        consumes less space for entities potentially hosted by several
        containers



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
  sorted.


* 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
  running.

  While I agree that having a complete "transform" api (rather than
  carbon copy) is desirable, it is not there yet and should not be
  rushed.

  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.

Kind regards,
Aurélien.






More information about the Cubicweb mailing list