Switch off automatic workspace assignment

[jri]

The automatic workspace assignment for each topic/association created should be switchable on/off on a per-request basis. (Analogous to the geocoder of the Geomaps module.)

We need this in conjunction with #751

[Jörg Richter <jri@…>]

In 59c22844ed14aeb82cf54a013a743259539e3755/deepamehta:

Suppress workspace assignment per-request (#752).

The automatic workspace assignment for all topics/associations created during processing a request can be switched off by adding the query parameter no_workspace_assignment to the request.

no_workspace_assignment=true

See #752.

[jri]

The current realization as a query parameter is not suitable for 3 reasons:

1. A finer granularity is needed. Consider method A calls method B. The workspace assignment might need be suppressed inside method B but not inside method A.

2. A reconceptualization is needed. Actually its not up to the caller to decide to suppress workspace assignment. Instead it depends on the semantic of the respective method. (In this regard suppressing workspace assignment is not like suppressing geocoding (as mentionened in the ticket description). The latter is indeed optional and to be decided by the caller.)

3. The caller might forget to add the query parameter and then things doesn't work as expected.

[Jörg Richter <jri@…>]

In ea0834b0acacbd625ce84aaf35dae9e61e3785b1/deepamehta:

Redesign workspace assignment suppression (#752).

BREAKING CHANGES

As a user of a REST API you must no longer care about adding the no_workspace_assignment query parameter to your request. The no_workspace_assignment query parameter has no function anymore. It is obsolete.

As a developer of a service you explicitly control which code blocks must execute without the standard workspace assignments. You do so by calling runWithoutWorkspaceAssignment() (part of Core's access control support).

Example:

try {
    Topic result = dms.getAccessControl().runWithoutWorkspaceAssignment(new Callable<Topic>() {
        @Override
        public Topic call() {
            // All topics/associations created here will get no workspace assignment.
            //
            // You could do workspace assignment manually (either by using the Workspaces
            // service or by `dms.getAccessControl().assignToWorkspace()`).
            //
            return aTopic;
        }
    });
} catch (Exception e) {
    throw new RuntimeException("Operation failed", e);
}

You pass your code block as a java.util.concurrent.Callable. The standard workspace assignment for all topics/associations created within that code block is suppressed then.

Your Callable can return a result object. That object will be finally returned by runWithoutWorkspaceAssignment(). The type parameter of the Callable is the type of the result object.

The runWithoutWorkspaceAssignment() method throws Exception, so you must catch or declare it.

runWithoutWorkspaceAssignment() calls can be nested. So you can safely call all 3rd-party API's from within the Callable.

See #752.

[Jörg Richter <jri@…>]

In 0582ce1a448fd5923b42c9e949cd77a3a0006504/deepamehta:

Adapt plugins to new workspace suppression (#752).

See #752.

[Jörg Richter <jri@…>]

In 4fe13ed237521182b527059132bf0a3d758b2832/deepamehta:

Core: fix workspace suppression (#752).

See #752.

[Malte]

Assessment:
This means that workspace suppression over all core methods/endpoints is uniform and not possible per Request anymore. If one needs to prevent workspace assignment one must create a new REST endpoint which wraps the core.

Question:
How is it with Associations? Don't have Associations have workspace assigments too?

[Malte]

Background here is uncritical, just an issue of optimization:
The dm4-wikidata search plugin must make sure that a topic with a wikidata uri never lies in a "Private Workspace" or a workspace a caller might not have READ access too. Instead of re-assigning all the topics to the Wikidata workspace, it would be more optimal (performance wise) if no assignment exists (in postCreateTopic) in first place.

The question "How is this with Associations?" is just interesting for me because i want to estimate how much work it will be and what needs to be done to switch to a wikidata search plugin which creates everything (topics and assocs) under the privileged runWithoutWorkspaceAssignment-call.

[Malte]

Please forget about my question: "How is this with associations" as it is incomplete and makes no sense to me. In the provided method one can do assignments of topics and associations as described in the comments.
I was just wondering if there is a reason why the return Type of the (runWithoutWorkspaceAssignment) construct is a Topic and not a DeepMehtaObject?.

[jri]

Replying to Malte:

I was just wondering if there is a reason why the return Type of the (runWithoutWorkspaceAssignment) construct is a Topic [...]

That's not quite correct. It's you who decides what Type the runWithoutWorkspaceAssignment() method returns. You do so by passing that type as a type parameter to the Callable you provide.

Look at the runWithoutWorkspaceAssignment() declaration:

public <V> V runWithoutWorkspaceAssignment(Callable<V> callable) throws Exception {

That is referred to in comment:5:

Your Callable can return a result object. That object will be finally returned by runWithoutWorkspaceAssignment(). The type parameter of the Callable is the type of the result object.

See also the specification of the Callable interface:
​http://docs.oracle.com/javase/6/docs/api/index.html?java/util/concurrent/Callable.html

So, this would be perfectly fine:

    DeepaMehtaObject result = dms.getAccessControl().runWithoutWorkspaceAssignment(new Callable<DeepaMehtaObject>() {
        @Override
        public DeepaMehtaObject call() {
            DeepaMehtaObject o;
            ...
            return o;
        }
    });

Type parameters are introduced in Java 5 in conjunction with Generics:
​https://docs.oracle.com/javase/tutorial/java/generics/