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
