ah - sorry - didn't follow that. that makes sense to me. inVLabel and outVLabel are kinda awkward. +1 from me on that one.
On Tue, Jul 19, 2016 at 3:23 PM, Robert Dale <robd...@gmail.com> wrote: > On Tue, Jul 19, 2016 at 3:13 PM, Stephen Mallette <spmalle...@gmail.com> > wrote: > >> > >> > - VertexProperty and (edge) Property are implicit types. I don't know > >> > if this is ok. Could they ever be used outside of their parents where > >> > they would need to be typed? > >> > >> I agree with the VertexProperty remark. That's one last question I > wanted > >> to solve, if we go for typing Vertex and edges, do we include others? > The > >> full list I see then is : vertex/edge/vertexproperty/property/graph. > >> > >> However I am not sure how useful it is to have more than Vertex and > Edge. > >> As, when deserializing a Vertex for example, there's no question as to > what > >> is in the "properties" field of the Vertex, there are necessarily only > >> VertexProperties. However looking at the API, it seems like it is > supported > >> to write only a VertexProperty if one wants to (see > >> GraphWriter.writeVertexProperty()), so in that case, to me it makes > sense > >> to add the types for the elements of the list I described above. > @stephen > >> any thoughts about that ? > > > > > > I guess we should type them to be consistent and because they might > return > > independently of a Vertex/Edge as Robert suggests. > > > >> - Edges: > >> > - is in/outVLabel new? Couldn't find it in the API or any examples > of > >> this. > >> > - why not make inV/outV have proper vertices with labels (to satisfy > >> > the case previous case) instead of just IDs? This would also be more > >> > consistent with the API. > >> > >> I haven't touched that part, it was in the format before. I believe this > >> is a question for Stephen. > > > > > > Returning a "proper" vertex for inV/outV would be nice but it's > potentially > > forcing the underlying graph database to pull a lot of data when the user > > only requested an edge to be returned. I don't think we should go that > far. > > By "proper" I meant an object (type: vertex) that would have the data > that's already available - label, id. No extra trips to the db. Just > more intuitive packaging of that data. > > -- > Robert Dale >
