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_ · Accepted solution]

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

[Robert Reiner _smartics_]

Hi @oliver.glowa ,

I just would like to confirm that there is no issue when having a space in its own search space. It is filtered out when the space closure is calculated. The overhead for processing this information is negligible. But I would like to recommend not to do it.

The space itself is always added as the first space in a closure. So for space "C" and a space list declared as "A, B, C" the order would be "C, A, B". This is not relevant for search spaces as these are added as constraint to the search (handled as a set), but it is relevant for delegate spaces where the order matters (handled as a list).

Regarding the need of reindexing: If you are using dynamic values you would need to manually reindex whenever you make changes to the space closures. This is not done automatically, because of the cost of reindex.

This is not necessary if the dynamic macros (Display Table Macro, et al.) are used in the document body (as opposed to as property values) as the space closure is calculated per request. But if the result of a query is stored as a dynamic property value (which use is typically not recommended), then all these pages need to be recalculated (reindexed).

If you have further questions, or if your use case is different from what I am assuming here, please get in touch!

Cheers,
Robert

[oliver.glowa]

Hi @Robert Reiner _smartics_ ,

thanks for your fast and detailed answer.

CU, Oliver

[oliver.glowa]

Hi @Robert Reiner _smartics_ ,

thanks for the fast and detailed answer.

CU, Oliver