Age | Commit message (Collapse) | Author |
|
IIncomingBoxBackend holds backend specific methods used for IncomingBox
implementation.
- Resolves: #8888
|
|
|
|
Improves error handling, add missing header to __init__.py and remove
mkdirs from flags methods. This is a commit from code review on !117.
|
|
Improve test naming, creates a "count" method and filter flags files
properly.
|
|
filter_flag parameter can now be used to filter listing blobs by a
specific flags. Eg: I can ask for blobs on incoming namespace flagged as pending.
-- Resolves: #8913
|
|
By using `only_count=True` parameter, instead of returning a full list,
server just count the amount of blobs.
-- Resolves: #8871
|
|
IncomingBox spec has a flags feature for the processing flow of
messages. This commit adds it using a .flags file.
-- Resolves: #8869
|
|
Updates IBlobsBackend with list_blobs order_by parameter and add a elif
clause to order_by checking, raising if the ordering parameter isn't
supported.
|
|
'namespace' argument is supported by backend but not yet exposed on API
for clients. Since IncomingBox makes heavy usage of it, this commit
exposes the argument as a query string for clients to use it.
|
|
Listing by date is useful for listing newest/oldest documents on blobs
storage and should be used for listing new IncomingMessages as described
on specification.
-- Resolves: #8879
|
|
We started with CouchDB due legacy system relying on it. This commit
adds the possibility of adding blobs as a IncomingAPI backend if blobs
is enabled on config file.
-- Resolves: #8868
|
|
We started with CouchDB due legacy system relying on it. This commit
adds the possibility of adding blobs as a IncomingAPI backend if blobs
is enabled on config file.
-- Resolves: #8868
|
|
Adds an extra parameter called "namespace" on the backend interface and
on FileSystemBlobsBackend. This parameter overrides default id
partitioning and uses a separate folder for a custom namespace.
-- Resolves: #8889
|
|
We have been discussing about this merge for a while.
Its main goal is to simplify things: code navigation, but also
packaging.
The rationale is that the code is more cohesive in this way, and there's
only one source package to install.
Dependencies that are only for the server or the client will not be
installed by default, and they are expected to be provided by the
environment. There are setuptools extras defined for the client and the
server.
Debianization is still expected to split the single source package into
3 binaries.
Another avantage is that the documentation can now install a single
package with a single step, and therefore include the docstrings into
the generated docs.
- Resolves: #8896
|