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