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