[Cubicweb] Enhancing `bulk` writes in CubicWeb
Adrien Di Mascio
adimasci at gmail.com
Mon May 5 22:48:56 CEST 2014
On Fri, May 2, 2014 at 3:05 PM, Aurélien Campéas <
aurelien.campeas at logilab.fr> wrote:
> The API is as such:
> * `insert_entities` (etype, entitiesdicts, postprocessentity)
> * `insert_relations` (rtype, fromtoentities)
> * `run_deferred_hooks` (errorslist)
What exactly does run_deferred_hooks() do ?
> The first problem with cubicweb/server/hook.py is that it is barely
> possible to understand the code. A serious refactoring is overdue.
Could you elaborate a bit more ? I don't pretend this is the best piece of
code ever but I find it at least readable.
To sum up: we want the code to be properly TYPED and LEXICALLY SCOPED.
I would also prefer explicit parameters rather than hooks holding a state.
> Notation-wise, we might even want something simpler::
> @entityhook(__select__ = is_instance('Elephant') & ~king(),
> events = ('after_add_entity', 'after_update_entity'))
> def babar_validation(session, event, entity):
I've experimented this kind of notation and find it nice.
> Fact is, it does not make a lot of sense for hooks to compete ... For
> one __regid__, we might want that only one hook exists, and not play
> the _select_best game.
I agree. Unlike views or components, we usually don't have several
implementations for a given __regid__. Is there any actual counter example
> Hooks can be deactivated only by 'category'. However, categories are
> not tags (one hook can belong to just one category), and we often need
> to deactivate down to the __regid__.
Wouldn't __regid__ disappear in your implementation ?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cubicweb