Term buckets on both engines: bleve folds them from doc values (its facets read numbers as prefix-coded terms), OpenSearch uses terms aggregations. A request gets every bucket, up to 65535 per space (the OpenSearch default for search.max_buckets, held on bleve as well); beyond that it is refused. The proto gains AggregationOption, BucketDefinition (sort, minimum count), AggregationResult and Bucket. The new aggregation package merges the per-space results by position, so several aggregations on one field stay apart, and shapes them per BucketDefinition (minimum count, sort, size). It also validates aggregations against the index mapping (a field the index knows and a client may name, of a type whose values are buckets; the mapping overrides mark the internal fields): the search service relies on it, the graph endpoint asks it first to save the round trip, next to its own checks against the spec, and with the field names of the request so an error reads like the request. A request names a field like the driveItem property, exactly so. A number is keyed as it is, a bool as true or false on both engines, an empty value is no bucket. Pinned in the parity suite as AGG-01 to 03, 17, 34, 37 and 39; the paging rows AGG-41 to 43 pin the first commit through the same matrix machinery, which also shortens long answer lists in the README.
Server Backend
Tip
For general information about OpenCloud and how to install please visit OpenCloud on Github and OpenCloud GmbH.
This is the main repository of the OpenCloud server. It contains the golang codebase for the backend services.
Getting Involved
The OpenCloud server is released under Apache 2.0. The project is thrilled to receive contributions in all forms. Start hacking now, there are many ways to get involved such as:
- Reporting issues or bugs
- Requesting features
- Writing documentation
- Writing code or extend our tests
- Reviewing code
- Helping others in the community
Every contribution is meaningful and appreciated! Please refer to our Contribution Guidelines if you want to get started.
Build OpenCloud
To build the backend, follow these instructions:
Generate the assets needed by e.g., the web UI and the builtin IDP
make generate
Then compile the opencloud binary
make -C opencloud build
That will produce the binary opencloud/bin/opencloud. It can be started as a local test instance right away with a two step command:
opencloud/bin/opencloud init && opencloud/bin/opencloud server
This creates a server configuration (by default in $HOME/.opencloud) and starts the server.
For more setup- and installation options consult the Development Documentation.
Technology
Important information for contributors about the technology in use.
Authentication
The OpenCloud backend authenticates users via OpenID Connect using either an external IdP like Keycloak or the embedded LibreGraph Connect identity provider.
Database
The OpenCloud backend does not use a database. It stores all data in the filesystem. By default, the root directory of the backend is $HOME/.opencloud/.
Security
If you find a security-related issue, please contact security@opencloud.eu immediately.
