Hi team, I'm not sure what the process to request this is, but would you be able to release a new version of the client? I'm working on the project that heavily relies on aggregators. The changes to the GroupBy query clause to support filter and limit is really exciting for me to see! It makes the code so much neater and the contract looks extremely easy to work with. I'd love to see it in an official release 🙏

Per the Pilosa documentation, GroupBy can be used with a filter option:
https://www.pilosa.com/docs/latest/query-language/#read-operations

The optional filter argument takes any type of Row query (e.g. Row, Union, Intersect, etc.) which will be intersected with each result prior to returning the count. This is analogous to a WHERE clause applied to a relational GROUP BY query.

Currently this is not supported via the Java client.
https://github.com/pilosa/java-pilosa/blob/master/com.pilosa.client/src/main/java/com/pilosa/client/orm/Index.java#L322

Everything is simply concatenated with a comma, meaning I have to convert the query to a string, add the filter=(...) string myself, then cast it back to a PqlQuery

This means that that result of inverseBitmapQuery cannot be used in union, intersect, etc.

Client version: 1.3.3, server version: 1.3.1 and master

As per the title, it seems the timestamp isn't being set when using the bulk importer. I've tried with both epoch millis and epoch seconds, and neither seem to work.

It seems the timestamp field is getting set on the protobufs payload, but it's not getting picked up by the server. If it looks like a problem with the server I can raise there too.

Configure diagnostics to be disabled during integration tests in Travis CI.

Docs on doing that here: https://www.pilosa.com/docs/latest/administration/#diagnostics

PqlBatchQuery :
line 116:

    public void add(PqlQuery query) {
        if (query.getIndex() != this.getIndex()) {
// Should be: if (!query.getIndex().getName().equals(this.getIndex().getName())) {
            throw new PilosaException("Query index should be the same as PqlBatchQuery index");
        }
        this.queries.add(query);
    }

Hi,
First of all, I'd like to thank you for making pilosa OS and available freely.
We have been using 2.0 from master branch for a while now.

During write operations if the cluster is not in ready state is it possible to handle these without throwing exceptions? A check prior to every operation might be costly, but how about providing a subscription end point on the server side to broadcast a state like writable readable unavailable

As per the title, the java client drops the keys option when setting the field type to time quantum, despite the server supporting this setting. I'm currently using version 1.3.0 of the java client.

FieldOptions.builder().fieldTime(TimeQuantum.YEAR_MONTH_DAY_HOUR).setKeys(true).build().isKeys() == true

However the output of toString is {"options":{"timeQuantum":"YMDH","type":"time"}}.

Pilos will accept field options for time quantum with a string field when the following options are posted via curl: { "options": { "keys": true, "timeQuantum":"YMDH","type":"time" } }

line 154:

public PqlBaseQuery set(String rowKey, String columnKey) {
return this.index.pqlQuery(String.format("Set(%s,%s='%s')",
columnKey, name, rowKey));
}

QueryResult doesn't appear to have any method to access the boolean response from SetBit or ClearBit. I could be missing it, but all the example code also neglects the response.