(TINKERPOP 3.0.0-incubating) Questions

[huneau romain <hu...@gmail.com>]

Hello,

I have some question, again.

First, maybe is the correct behaviour, but it's weird. In the Driver /
Client class, you have a submit method :
    /**
     * Submits a Gremlin script and bound parameters to the server and
returns a {@link ResultSet} once the write of
     * the request is complete. .....
    */
    public ResultSet submit(final String gremlin, final Map<String, Object>
parameters) {
        try {
            return submitAsync(gremlin, parameters).get();
        } catch (Exception ex) {
            throw new RuntimeException(ex);
        }
    }

Here for avoid bug in our client we need to "re-wait" just after the submit
with :
client.submit("our request").all().get(); //to be sure than the response is
complete
or :
while (!client.submit("our request").allItemsAvailable());
It's strange to do that in a synchronous method.

Next, it's about log, we would like to have our own layer/pattern and log4j
conf are hard coded into the gremlin.sh. I think put the log4j conf file
into the line args maybe be a good solution, right ?. (If we change the
gremlin.sh we will have some difficult to merge with yours later).
And Probably an other suggestion will let the User API to provide the
LogManager, but more tricky.

Romain.

Re: (TINKERPOP 3.0.0-incubating) Questions

[Stephen Mallette <sp...@gmail.com>]

ResultSet might not have been the best name perhaps as it implies the
"result" should be in hand.  It's more of a ResultStream or ResultFuture -
maybe still not great names.  In the case of submit() the ResultSet is
returned only after there is confirmation that the send of the request hits
the network stack.  You then have the option to wait for all() or some()
results from there.  I've been thinking about having two separate ResultSet
classes one for a synchronous return and one for asynchronous return, but
thought I'd wait for more user feedback before making changes.  I'd say
that appropriate usage to wait for all results would be:

client.submit("our request").all().get();

or

client.submit("our request").all().join();

you might also consider this blocking iterator that will allow you to start
processing results as they arrive:

Iterator itty = client.submit("our request").iterator()
while(itty.hasNext()) {
    ....
}

> Next, it's about log, we would like to have our own layer/pattern and
log4j conf are hard coded into the gremlin.sh. I think put the log4j conf
file into the line args maybe be a good solution, right ?.

If you'd like to submit a pull request to alter gremlin.sh to allow for a
user specified log4j.configuration setting, I think that's fine.  Looks
like we already have a mechanism for that when setting the log level.  I
would think that you would simply follow that pattern.


On Fri, Jul 31, 2015 at 4:57 AM, huneau romain <hu...@gmail.com>
wrote:

> Hello,
>
> I have some question, again.
>
> First, maybe is the correct behaviour, but it's weird. In the Driver /
> Client class, you have a submit method :
>     /**
>      * Submits a Gremlin script and bound parameters to the server and
> returns a {@link ResultSet} once the write of
>      * the request is complete. .....
>     */
>     public ResultSet submit(final String gremlin, final Map<String, Object>
> parameters) {
>         try {
>             return submitAsync(gremlin, parameters).get();
>         } catch (Exception ex) {
>             throw new RuntimeException(ex);
>         }
>     }
>
> Here for avoid bug in our client we need to "re-wait" just after the submit
> with :
> client.submit("our request").all().get(); //to be sure than the response is
> complete
> or :
> while (!client.submit("our request").allItemsAvailable());
> It's strange to do that in a synchronous method.
>
> Next, it's about log, we would like to have our own layer/pattern and log4j
> conf are hard coded into the gremlin.sh. I think put the log4j conf file
> into the line args maybe be a good solution, right ?. (If we change the
> gremlin.sh we will have some difficult to merge with yours later).
> And Probably an other suggestion will let the User API to provide the
> LogManager, but more tricky.
>
> Romain.
>