> My proposal is to always have some detachment strategy in server
configuration and add `DetachedStrategy` to allow users the flexibility to
customize the result.
I think default detachment on the server should remain "reference" so if
you can do that with your new DetachStrategy then that is preferred with
the idea that HaltedTraverserStrategy is no longer useful and can be
deprecated.
> How to handle more than one DetachedStrategy?
I agree that they shouldn't stack - DetachedStrategy should not be used for
some sort of security use case. A client-side one should replace the
server-side one.
> Another question is whether or not to show `DetachElementStep` in the
response for profiling requests like `g.V().profile()`.
This is the hardest question and goes back to the first because you will be
using DetachStrategy by default on the server side and, as a result, when
the user does their g.V().profile() without using DetachStrategy they will
see your DetachElementStep even though they didn't add one on the client
side. Right now we hide the detachment behind HaltedTraverserStrategy (for
bytecode based requests) and in the default configuration of
ReferenceElementStrategy in the startup script. The latter makes the former
a bit redundant actually.
It seems that for script based requests we see ReferenceElementStep now in
the profile():
gremlin> :> g.V().profile()
==>Traversal Metrics
Step Count
Traversers Time (ms) % Dur
=============================================================================================================
TinkerGraphStep(vertex,[]) 6
6 0.623 37.21
ReferenceElementStep 6
6 1.052 62.79
>TOTAL -
- 1.676 -
I don't particularly like that but it might be helpful to see that the
detachment is explicitly happening by way of a step.This line of thinking
has me wondering if we should remove the default detachment all together
from Gremlin Server configuration:
1. Most folks should not be relying on ReferenceElementStrategy to protect
them from fat elements, because we've spent years pushing them toward
valueMap(), project(), etc. If they suddenly started getting properties on
elements I sense that wouldn't affect many people negatively.
2. With ease of use and intuitive behavior in mind, new users will expect
properties to be on their elements.
3. Removing default detachment would make it so that the DetachElementStep
only appears when the user explicitly sets it themselves. There would be no
surprise that it is there in the profile().
4. The notion of default detachment would then fall to the serializers
which would just include all properties in a DetachedElement.
If TinkerPop took this route then we'd have to be sure to warn users of (1)
possible increased serialization times if they were relying on elements
having no properties and (2) the fact that if they wrote their code to
explicitly use a ReferenceVertex they will need to add "reference"
detachment or generalize their code to the Element interfaces. Maybe some
other stuff too?
On Fri, Nov 18, 2022 at 5:30 PM Valentyn Kahamlyk
<valent...@bitquilltech.com.invalid> wrote:
> Hi everyone,
>
> I'm working on properties on elements (
> https://issues.apache.org/jira/browse/TINKERPOP-2824).
> I found HaltedTraverserStrategy` in `TraverserIterator` that does about the
> same, converting Elements to detached or references. Tests use reference
> Elements, and detached is default for production. GLV's possibly can
> override strategy to get different results.
> My implementation of `DetachedStrategy` is to add the last step to the
> traversal which modifies the result, so, technically g.V() becomes
> g.V().[DetachStep].
> Also default server configuration adds ReferenceElementStrategy
>
> https://github.com/apache/tinkerpop/blob/master/gremlin-server/scripts/empty-sample.groovy#L45
> to each traversal.
>
> 1. So I end up with 3 ways to cut properties and I'm not sure how to handle
> it. What options would you suggest?
> My proposal is to always have some detachment strategy in server
> configuration and add `DetachedStrategy` to allow users the flexibility to
> customize the result. `HaltedTraverserStrategy` can be marked deprecated as
> it handles only bytecode traversal, but not used for scripts.
> Another side of the problem is the need to detach custom vertex
> implementations like `TinkerVertex`.
>
> 2. How to handle more than one `DetachedStrategy`? For example one can be
> set in Gremlin Server configuration and other in user traversal.
> Options:
> a) apply all. Each successive DetachStrategy becomes more restrictive.
> b) apply only last one. Use case: there are default server configurations
> to return only some properties and the user can override it for each
> request.
> I think both options make sense, but I prefer the second.
>
> 3. Another question is whether or not to show `DetachElementStep` in the
> response for profiling requests like `g.V().profile()`. Users may be
> confused at the appearance of a step that they did not add, but on the
> other hand it will be an explanation why there are no properties in the
> response.
> Is it better to hide `DetachElementStep` or vice versa?
>
> Thanks, Valentyn
>
