Hi,
Right now, there is only one nodetype index. So, if you add a nodetype / mixin
to that index (as you know the lists of nodetypes / mixins is a multi-valued
property), then you need to reindex that index. Which needs to read all the
nodes.
The alternative would be to have multiple nodetype indexes. A patch for that is
welcome! If you have that, then instead of changing the nodetype index, you
create a new index. This also needs to read all the nodes.
So, that would be more convenient (even though in both cases indexing a new
nodetype takes about the same time).
> Is this a design choice to only allow one nodetype index?
Not a design choice, just how it is implemented right now.
> I have no way to make it contained in the project itself to make an index
> based on it's mixin type.
There is a way, you need some code to extend the existing nodetype index, and
then reindex.
Regards,
Thomas
On 29.06.17, 16:42, "Roy Teeuwen" <r...@teeuwen.be> wrote:
Hey all,
Some time ago I asked about creating an oak index based on the node type
(primary type or mixin type), after which I was pointed to the nodetype index.
I have to say though that there is a serious drawback to this index:
I have two separate projects, both having some code based on a mixinType.
But seeing as there can only be one nodetype index, I have no way to make it
contained in the project itself to make an index based on it's mixin type.
Is this a design choice to only allow one nodetype index? Is there a
workaround for this?
Thanks!
Roy
