[QUESTION] user supplied string Ids

[Jonathan Ellithorpe <jd...@cs.stanford.edu>]

Hello,

I've implemented support for being able to supply String type user supplied
IDs, and being able to retrieve vertices based on a given String type
supplied ID. However, I am failing the following test:

shouldAddVertexWithUserSuppliedStringId

Because the test is testing to see if:

assertEquals("1000", v.id());

It seems that the test is assuming that v.id() is a String, which it isn't
for my implementation, it's a custom type. Why is the test assuming that
v.id() returns a String?

Best,
Jonathan

Re: [QUESTION] user supplied string Ids

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

Hard for me to answer as it sounds like you're asking: "How should my
implementation work?" I can try to offer an opinion since you are asking....

First of all, sounds like a bit of a strange use case in a way.  A "user"
is typically someone on the end of an application who doesn't care about
the id and it's type.  Application logic hides that detail from them and
they will more likely use logical indices to find data.  In that sense, a
developer chooses a type for ids and sticks with it.  Even if you were
hosting a multi-tenant application where the user was creating graphs, i'd
think the use of the element identifier as something hidden.

But let's say that there's a use case out there like you say for argument
sake.  I guess I would side with the TinkerGraph route:

gremlin> graph = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> graph.addVertex(id,123)
==>v[123]
gremlin> graph.addVertex(id,"123")
==>v[123]
gremlin> graph.vertices(123)
==>v[123]
gremlin> graph.vertices("123")
==>v[123]

and let's say we configure TinkerGraph to coerce ids to Long which:

gremlin> conf = new BaseConfiguration()
==>org.apache.commons.configuration.BaseConfiguration@2873d672
gremlin> conf.setProperty("gremlin.graph", TinkerGraph.class.getName())
==>null
gremlin> conf.setProperty("gremlin.tinkergraph.vertexIdManager", "LONG")
==>null
gremlin> graph = TinkerGraph.open(conf)
==>tinkergraph[vertices:0 edges:0]
gremlin> graph.addVertex(id,123)
==>v[123]
gremlin> graph.addVertex(id,"123")
Vertex with id already exists: 123
Display stack trace? [yN] n
gremlin> graph.vertices("123")
==>v[123]
gremlin> graph.vertices(123)
==>v[123]
gremlin> graph.vertices(123L)
==>v[123]


On Wed, Dec 9, 2015 at 3:14 PM, Jonathan Ellithorpe <jd...@cs.stanford.edu>
wrote:

> Ya... I see your point. As a user you'll probably pick a type and stick
> with it, so if you create a vertex with a String ID, then vertex.id()
> should return a type String. That makes sense. I think one more question
> ought to clear up my last bit of confusion. Suppose you have two users
> interacting with the same database, user A is using String-type IDs and
> user B is using BigInteger-type IDs. When user B reads vertices created by
> user A (say user A creates a vertex with ID "1" and B reads a vertex with
> ID BigInteger(1)), the result should be 1) a vertex with id() return type
> String, 2) vertex with id() return type BigInteger, 3) error: no vertex
> exists with ID BigInteger(1).
>
> My guess is the expected behavior should be 2, but I want to just confirm.
>
> Thanks for your help!
> Jonathan
>
> On Wed, Dec 9, 2015 at 8:42 AM Stephen Mallette <sp...@gmail.com>
> wrote:
>
> > > Is it a requirement of the API that fetching the first vertex from
> > database
> > preserve String as the returned data type of v1.id() and Long as the
> > returned data type of v2.id() for all time?
> > > Perhaps it seems equally odd to the user to receive a different data
> > type back
> > from vertex.id() than they used to specify the ID in the first place?
> >
> > i don't think it's wrong for you to do things the way you are doing them
> > but I would say that if I were a user and I gave you a String and you
> > returned back SomeCustomObject or UUID, i think i'd get confused. i'm not
> > sure that i know of any graph that behaves that way and given the test
> > you've referenced we've not expected it to.  But this is precisely the
> > reason we've given providers the opportunity to OptOut of tests that
> don't
> > specifically conform to a capability they have.  In time, perhaps we can
> do
> > different id tests that work for everyone and you can drop the OptOut.
> >
> > >  suppose I create a vertex using a String ID and then fetch it with a
> > Long ID. What is the return type of vertex.id()?
> >
> > i dunno - i would think that in most applications, if i'm allowed to
> assign
> > ids, i will choose my type and stick with it consistently.
> >
> > On Wed, Dec 9, 2015 at 11:37 AM, Jonathan Ellithorpe <
> jde@cs.stanford.edu>
> > wrote:
> >
> > > Sorry for not including this in the first email, but here's another
> > > problem: suppose I create a vertex using a String ID and then fetch it
> > with
> > > a Long ID. What is the return type of vertex.id()?
> > > On Wed, Dec 9, 2015 at 8:34 AM Jonathan Ellithorpe <
> jde@cs.stanford.edu>
> > > wrote:
> > >
> > > > Ya I don't think that makes sense, but let me talk this through and
> see
> > > if
> > > > I'm missing something... Internally my database uses 128bit vertex
> > > > identifiers, so I have a custom internal data type to represent that
> > ID.
> > > > But I want to allow the user to be able to hand me IDs of many
> > different
> > > > types for convenience, like type String, Long, Int, UUID, BigInteger,
> > > etc.
> > > > when they call addVertex or the vertices() method. Internally,
> however,
> > > > whether they were created with Longs or Strings and then fetched with
> > > > BigIntegers or Shorts, I currently convert all these to my internal
> > > > representation and that is what is returned by the vertex.id()
> method
> > > > call. If the API required that vertex.id() return the same object
> type
> > > > that was used as a user supplied ID on the addVertex() call, then the
> > API
> > > > is forcing the database to have to remember that information. Imagine
> > one
> > > > day creating a vertex v1 using a String ID, and the next day creating
> > one
> > > > (v2) using a Long ID. Is it a requirement of the API that fetching
> the
> > > > first vertex from the database preserve String as the returned data
> > type
> > > of
> > > > v1.id() and Long as the returned data type of v2.id() for all time?
> > > Maybe
> > > > I'm not understanding something but that seems like an odd
> requirement
> > of
> > > > the API. Perhaps it seems equally odd to the user to receive a
> > different
> > > > data type back from vertex.id() than they used to specify the ID in
> > the
> > > > first place? Has this problem been discussed before?
> > > >
> > > > Best,
> > > > Jonathan
> > > > On Wed, Dec 9, 2015 at 3:49 AM Stephen Mallette <
> spmallette@gmail.com>
> > > > wrote:
> > > >
> > > >> The test assumes some symmetry.  I pass in a String as my
> identifier,
> > > and
> > > >> I
> > > >> get back a String - logical, no?
> > > >>
> > > >> Are you saying that you transform the String that the user supplies
> > to a
> > > >> custom type, such that when they call id() they don't get a String?
> > > >>
> > > >> On Wed, Dec 9, 2015 at 12:58 AM, Jonathan Ellithorpe <
> > > jde@cs.stanford.edu
> > > >> >
> > > >> wrote:
> > > >>
> > > >> > Hello,
> > > >> >
> > > >> > I've implemented support for being able to supply String type user
> > > >> supplied
> > > >> > IDs, and being able to retrieve vertices based on a given String
> > type
> > > >> > supplied ID. However, I am failing the following test:
> > > >> >
> > > >> > shouldAddVertexWithUserSuppliedStringId
> > > >> >
> > > >> > Because the test is testing to see if:
> > > >> >
> > > >> > assertEquals("1000", v.id());
> > > >> >
> > > >> > It seems that the test is assuming that v.id() is a String, which
> > it
> > > >> isn't
> > > >> > for my implementation, it's a custom type. Why is the test
> assuming
> > > that
> > > >> > v.id() returns a String?
> > > >> >
> > > >> > Best,
> > > >> > Jonathan
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: [QUESTION] user supplied string Ids

[Jonathan Ellithorpe <jd...@cs.stanford.edu>]

Ya... I see your point. As a user you'll probably pick a type and stick
with it, so if you create a vertex with a String ID, then vertex.id()
should return a type String. That makes sense. I think one more question
ought to clear up my last bit of confusion. Suppose you have two users
interacting with the same database, user A is using String-type IDs and
user B is using BigInteger-type IDs. When user B reads vertices created by
user A (say user A creates a vertex with ID "1" and B reads a vertex with
ID BigInteger(1)), the result should be 1) a vertex with id() return type
String, 2) vertex with id() return type BigInteger, 3) error: no vertex
exists with ID BigInteger(1).

My guess is the expected behavior should be 2, but I want to just confirm.

Thanks for your help!
Jonathan

On Wed, Dec 9, 2015 at 8:42 AM Stephen Mallette <sp...@gmail.com>
wrote:

> > Is it a requirement of the API that fetching the first vertex from
> database
> preserve String as the returned data type of v1.id() and Long as the
> returned data type of v2.id() for all time?
> > Perhaps it seems equally odd to the user to receive a different data
> type back
> from vertex.id() than they used to specify the ID in the first place?
>
> i don't think it's wrong for you to do things the way you are doing them
> but I would say that if I were a user and I gave you a String and you
> returned back SomeCustomObject or UUID, i think i'd get confused. i'm not
> sure that i know of any graph that behaves that way and given the test
> you've referenced we've not expected it to.  But this is precisely the
> reason we've given providers the opportunity to OptOut of tests that don't
> specifically conform to a capability they have.  In time, perhaps we can do
> different id tests that work for everyone and you can drop the OptOut.
>
> >  suppose I create a vertex using a String ID and then fetch it with a
> Long ID. What is the return type of vertex.id()?
>
> i dunno - i would think that in most applications, if i'm allowed to assign
> ids, i will choose my type and stick with it consistently.
>
> On Wed, Dec 9, 2015 at 11:37 AM, Jonathan Ellithorpe <jd...@cs.stanford.edu>
> wrote:
>
> > Sorry for not including this in the first email, but here's another
> > problem: suppose I create a vertex using a String ID and then fetch it
> with
> > a Long ID. What is the return type of vertex.id()?
> > On Wed, Dec 9, 2015 at 8:34 AM Jonathan Ellithorpe <jd...@cs.stanford.edu>
> > wrote:
> >
> > > Ya I don't think that makes sense, but let me talk this through and see
> > if
> > > I'm missing something... Internally my database uses 128bit vertex
> > > identifiers, so I have a custom internal data type to represent that
> ID.
> > > But I want to allow the user to be able to hand me IDs of many
> different
> > > types for convenience, like type String, Long, Int, UUID, BigInteger,
> > etc.
> > > when they call addVertex or the vertices() method. Internally, however,
> > > whether they were created with Longs or Strings and then fetched with
> > > BigIntegers or Shorts, I currently convert all these to my internal
> > > representation and that is what is returned by the vertex.id() method
> > > call. If the API required that vertex.id() return the same object type
> > > that was used as a user supplied ID on the addVertex() call, then the
> API
> > > is forcing the database to have to remember that information. Imagine
> one
> > > day creating a vertex v1 using a String ID, and the next day creating
> one
> > > (v2) using a Long ID. Is it a requirement of the API that fetching the
> > > first vertex from the database preserve String as the returned data
> type
> > of
> > > v1.id() and Long as the returned data type of v2.id() for all time?
> > Maybe
> > > I'm not understanding something but that seems like an odd requirement
> of
> > > the API. Perhaps it seems equally odd to the user to receive a
> different
> > > data type back from vertex.id() than they used to specify the ID in
> the
> > > first place? Has this problem been discussed before?
> > >
> > > Best,
> > > Jonathan
> > > On Wed, Dec 9, 2015 at 3:49 AM Stephen Mallette <sp...@gmail.com>
> > > wrote:
> > >
> > >> The test assumes some symmetry.  I pass in a String as my identifier,
> > and
> > >> I
> > >> get back a String - logical, no?
> > >>
> > >> Are you saying that you transform the String that the user supplies
> to a
> > >> custom type, such that when they call id() they don't get a String?
> > >>
> > >> On Wed, Dec 9, 2015 at 12:58 AM, Jonathan Ellithorpe <
> > jde@cs.stanford.edu
> > >> >
> > >> wrote:
> > >>
> > >> > Hello,
> > >> >
> > >> > I've implemented support for being able to supply String type user
> > >> supplied
> > >> > IDs, and being able to retrieve vertices based on a given String
> type
> > >> > supplied ID. However, I am failing the following test:
> > >> >
> > >> > shouldAddVertexWithUserSuppliedStringId
> > >> >
> > >> > Because the test is testing to see if:
> > >> >
> > >> > assertEquals("1000", v.id());
> > >> >
> > >> > It seems that the test is assuming that v.id() is a String, which
> it
> > >> isn't
> > >> > for my implementation, it's a custom type. Why is the test assuming
> > that
> > >> > v.id() returns a String?
> > >> >
> > >> > Best,
> > >> > Jonathan
> > >> >
> > >>
> > >
> >
>

Re: [QUESTION] user supplied string Ids

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

> Is it a requirement of the API that fetching the first vertex from  database
preserve String as the returned data type of v1.id() and Long as the
returned data type of v2.id() for all time?
> Perhaps it seems equally odd to the user to receive a different data type back
from vertex.id() than they used to specify the ID in the first place?

i don't think it's wrong for you to do things the way you are doing them
but I would say that if I were a user and I gave you a String and you
returned back SomeCustomObject or UUID, i think i'd get confused. i'm not
sure that i know of any graph that behaves that way and given the test
you've referenced we've not expected it to.  But this is precisely the
reason we've given providers the opportunity to OptOut of tests that don't
specifically conform to a capability they have.  In time, perhaps we can do
different id tests that work for everyone and you can drop the OptOut.

>  suppose I create a vertex using a String ID and then fetch it with a
Long ID. What is the return type of vertex.id()?

i dunno - i would think that in most applications, if i'm allowed to assign
ids, i will choose my type and stick with it consistently.

On Wed, Dec 9, 2015 at 11:37 AM, Jonathan Ellithorpe <jd...@cs.stanford.edu>
wrote:

> Sorry for not including this in the first email, but here's another
> problem: suppose I create a vertex using a String ID and then fetch it with
> a Long ID. What is the return type of vertex.id()?
> On Wed, Dec 9, 2015 at 8:34 AM Jonathan Ellithorpe <jd...@cs.stanford.edu>
> wrote:
>
> > Ya I don't think that makes sense, but let me talk this through and see
> if
> > I'm missing something... Internally my database uses 128bit vertex
> > identifiers, so I have a custom internal data type to represent that ID.
> > But I want to allow the user to be able to hand me IDs of many different
> > types for convenience, like type String, Long, Int, UUID, BigInteger,
> etc.
> > when they call addVertex or the vertices() method. Internally, however,
> > whether they were created with Longs or Strings and then fetched with
> > BigIntegers or Shorts, I currently convert all these to my internal
> > representation and that is what is returned by the vertex.id() method
> > call. If the API required that vertex.id() return the same object type
> > that was used as a user supplied ID on the addVertex() call, then the API
> > is forcing the database to have to remember that information. Imagine one
> > day creating a vertex v1 using a String ID, and the next day creating one
> > (v2) using a Long ID. Is it a requirement of the API that fetching the
> > first vertex from the database preserve String as the returned data type
> of
> > v1.id() and Long as the returned data type of v2.id() for all time?
> Maybe
> > I'm not understanding something but that seems like an odd requirement of
> > the API. Perhaps it seems equally odd to the user to receive a different
> > data type back from vertex.id() than they used to specify the ID in the
> > first place? Has this problem been discussed before?
> >
> > Best,
> > Jonathan
> > On Wed, Dec 9, 2015 at 3:49 AM Stephen Mallette <sp...@gmail.com>
> > wrote:
> >
> >> The test assumes some symmetry.  I pass in a String as my identifier,
> and
> >> I
> >> get back a String - logical, no?
> >>
> >> Are you saying that you transform the String that the user supplies to a
> >> custom type, such that when they call id() they don't get a String?
> >>
> >> On Wed, Dec 9, 2015 at 12:58 AM, Jonathan Ellithorpe <
> jde@cs.stanford.edu
> >> >
> >> wrote:
> >>
> >> > Hello,
> >> >
> >> > I've implemented support for being able to supply String type user
> >> supplied
> >> > IDs, and being able to retrieve vertices based on a given String type
> >> > supplied ID. However, I am failing the following test:
> >> >
> >> > shouldAddVertexWithUserSuppliedStringId
> >> >
> >> > Because the test is testing to see if:
> >> >
> >> > assertEquals("1000", v.id());
> >> >
> >> > It seems that the test is assuming that v.id() is a String, which it
> >> isn't
> >> > for my implementation, it's a custom type. Why is the test assuming
> that
> >> > v.id() returns a String?
> >> >
> >> > Best,
> >> > Jonathan
> >> >
> >>
> >
>

Re: [QUESTION] user supplied string Ids

[Jonathan Ellithorpe <jd...@cs.stanford.edu>]

Sorry for not including this in the first email, but here's another
problem: suppose I create a vertex using a String ID and then fetch it with
a Long ID. What is the return type of vertex.id()?
On Wed, Dec 9, 2015 at 8:34 AM Jonathan Ellithorpe <jd...@cs.stanford.edu>
wrote:

> Ya I don't think that makes sense, but let me talk this through and see if
> I'm missing something... Internally my database uses 128bit vertex
> identifiers, so I have a custom internal data type to represent that ID.
> But I want to allow the user to be able to hand me IDs of many different
> types for convenience, like type String, Long, Int, UUID, BigInteger, etc.
> when they call addVertex or the vertices() method. Internally, however,
> whether they were created with Longs or Strings and then fetched with
> BigIntegers or Shorts, I currently convert all these to my internal
> representation and that is what is returned by the vertex.id() method
> call. If the API required that vertex.id() return the same object type
> that was used as a user supplied ID on the addVertex() call, then the API
> is forcing the database to have to remember that information. Imagine one
> day creating a vertex v1 using a String ID, and the next day creating one
> (v2) using a Long ID. Is it a requirement of the API that fetching the
> first vertex from the database preserve String as the returned data type of
> v1.id() and Long as the returned data type of v2.id() for all time? Maybe
> I'm not understanding something but that seems like an odd requirement of
> the API. Perhaps it seems equally odd to the user to receive a different
> data type back from vertex.id() than they used to specify the ID in the
> first place? Has this problem been discussed before?
>
> Best,
> Jonathan
> On Wed, Dec 9, 2015 at 3:49 AM Stephen Mallette <sp...@gmail.com>
> wrote:
>
>> The test assumes some symmetry.  I pass in a String as my identifier, and
>> I
>> get back a String - logical, no?
>>
>> Are you saying that you transform the String that the user supplies to a
>> custom type, such that when they call id() they don't get a String?
>>
>> On Wed, Dec 9, 2015 at 12:58 AM, Jonathan Ellithorpe <jde@cs.stanford.edu
>> >
>> wrote:
>>
>> > Hello,
>> >
>> > I've implemented support for being able to supply String type user
>> supplied
>> > IDs, and being able to retrieve vertices based on a given String type
>> > supplied ID. However, I am failing the following test:
>> >
>> > shouldAddVertexWithUserSuppliedStringId
>> >
>> > Because the test is testing to see if:
>> >
>> > assertEquals("1000", v.id());
>> >
>> > It seems that the test is assuming that v.id() is a String, which it
>> isn't
>> > for my implementation, it's a custom type. Why is the test assuming that
>> > v.id() returns a String?
>> >
>> > Best,
>> > Jonathan
>> >
>>
>

Re: [QUESTION] user supplied string Ids

[Jonathan Ellithorpe <jd...@cs.stanford.edu>]

Ya I don't think that makes sense, but let me talk this through and see if
I'm missing something... Internally my database uses 128bit vertex
identifiers, so I have a custom internal data type to represent that ID.
But I want to allow the user to be able to hand me IDs of many different
types for convenience, like type String, Long, Int, UUID, BigInteger, etc.
when they call addVertex or the vertices() method. Internally, however,
whether they were created with Longs or Strings and then fetched with
BigIntegers or Shorts, I currently convert all these to my internal
representation and that is what is returned by the vertex.id() method call.
If the API required that vertex.id() return the same object type that was
used as a user supplied ID on the addVertex() call, then the API is forcing
the database to have to remember that information. Imagine one day creating
a vertex v1 using a String ID, and the next day creating one (v2) using a
Long ID. Is it a requirement of the API that fetching the first vertex from
the database preserve String as the returned data type of v1.id() and Long
as the returned data type of v2.id() for all time? Maybe I'm not
understanding something but that seems like an odd requirement of the API.
Perhaps it seems equally odd to the user to receive a different data type
back from vertex.id() than they used to specify the ID in the first place?
Has this problem been discussed before?

Best,
Jonathan
On Wed, Dec 9, 2015 at 3:49 AM Stephen Mallette <sp...@gmail.com>
wrote:

> The test assumes some symmetry.  I pass in a String as my identifier, and I
> get back a String - logical, no?
>
> Are you saying that you transform the String that the user supplies to a
> custom type, such that when they call id() they don't get a String?
>
> On Wed, Dec 9, 2015 at 12:58 AM, Jonathan Ellithorpe <jd...@cs.stanford.edu>
> wrote:
>
> > Hello,
> >
> > I've implemented support for being able to supply String type user
> supplied
> > IDs, and being able to retrieve vertices based on a given String type
> > supplied ID. However, I am failing the following test:
> >
> > shouldAddVertexWithUserSuppliedStringId
> >
> > Because the test is testing to see if:
> >
> > assertEquals("1000", v.id());
> >
> > It seems that the test is assuming that v.id() is a String, which it
> isn't
> > for my implementation, it's a custom type. Why is the test assuming that
> > v.id() returns a String?
> >
> > Best,
> > Jonathan
> >
>

Re: [QUESTION] user supplied string Ids

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

The test assumes some symmetry.  I pass in a String as my identifier, and I
get back a String - logical, no?

Are you saying that you transform the String that the user supplies to a
custom type, such that when they call id() they don't get a String?

On Wed, Dec 9, 2015 at 12:58 AM, Jonathan Ellithorpe <jd...@cs.stanford.edu>
wrote:

> Hello,
>
> I've implemented support for being able to supply String type user supplied
> IDs, and being able to retrieve vertices based on a given String type
> supplied ID. However, I am failing the following test:
>
> shouldAddVertexWithUserSuppliedStringId
>
> Because the test is testing to see if:
>
> assertEquals("1000", v.id());
>
> It seems that the test is assuming that v.id() is a String, which it isn't
> for my implementation, it's a custom type. Why is the test assuming that
> v.id() returns a String?
>
> Best,
> Jonathan
>