Projectdoc / Using Space Property search-space

oliver.glowa

Hello,

I'm getting a bit confused when using the Projectdoc Toolbox (PDT) Space Property "search-space".

Scenario

We have several spaces (A, B, C) with different aspects for the documentation. When using the "Display Table"/"Display List"/etc.-Macro should list all pages, which a matching according to the Where-Clause, from all three spaces. Defining the the field "space key", "space keys" for each macro is a failing solution.

So we defined the "search-space"-Property on the homepage of each space. Every space has to search in the two other spaces, so the space configuration (Document Properties Marker Macro) looks like:

In Space A -> "search-space"=A,B,C
In Space B -> "search-space"=A,B,C
In Space C -> "search-space"=A,B,C

Problem

But this seems to impact the performance of the space, when creating, updating or displaying pages in this spaces. Sometimes newly created pages are not displayed in the "Display Table"-Macro, you'll have to refresh the "PDT Index" prior.

Questions

1)

Is this the correct space configuration?
Or do I have to remove the "A" from Space A, "B" from Space B and "C" from Space C, because the current space is always a "search-space"?

2)

The documentation says: "The search space is typically exported".

Does this mean:
when quering with a macro from "Space A" with search-space="A,B,C",
the query/macro will see the configuration in "Space B" (search-space="A,B,C") and
will search again in "Space A" with search-space="A,B,C" and
will then search again in Space B with search-space="A,B,C" and so on,
like a neverending Mary-Go-Round?

References

• https://www.smartics.eu/confluence/display/PDAC1/Search+Space
• https://www.smartics.eu/confluence/display/PDAC1/Display+Table+Macro

 

Robert Reiner _smartics_

Hi @oliver.glowa,

the search space closure is used to define the default set of spaces to use for searching. Please keep in mind that not only the specified search space, for instance B, is part of the search space, but the complete search space of B. This is because it is assumed that if B searches in its search space, then other spaces that want to search in B should also use the search space closure of B.

If this would not be the case in your use case, that is: B should search differently than spaces having B in their search space, then you may want to define a local search space for B. Local search spaces are not exported and used exclusively by the space that defines it. In this sense the "search space" is typically exported, while the "local search space" is not.

The implementation of search spaces creates the search space closure (a collection of all space keys) and then adds the spaces of the closure as a constraint of the search. So there is only one search executed, but the calculation of the closure may take some time. The closure needs to be calculated for each request and space, but is then reused for all queries on that space(s).

There is no need to add the space to its own search space. Per design this should not be. The implementation however, should be capable to deal with that. I'll check if there is an issue with the implementation. If I find one, I'll report it here ...

I just wanted to quickly reply to your question to provide some insight on the workings behind the scenes.

Since you mentioned issues that can only be fixed with a projectdoc reindex: This is often caused by using dynamic values. This is especially an issue when running a rebuild or site reindex on an empty database.

If you like to share your configuration with us, you may also open a support ticket. In case you would like us to have a short look on your information architecture, we could run a quick one-on-one (just mention this in the ticket).

Cheers,
Robert