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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > 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 <[email protected]> > > > 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 < > > [email protected] > > >> > > > >> 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 > > >> > > > >> > > > > > >
