> 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 > >> > > >> > > >
