When you say "tinkerpop auto capturing schema information," are you thinking only about giving TP3 the ability to express the underlying datastore's schema, or are you also considering allowing a vendor-agnostic schema expression capability that could be used to configure the datastore? I guess the "auto capturing" term makes me think of the use case where the schema is encoded somewhere, and we want TP3 to import it, rather than the complementary capability of allowing TP3 to become a schema definition API.
I'm in favor of providing the ability to express graph schema, since it opens up many exciting possibilities, including the ones you mention, but also support for user-defined types (UDT's). UDT's could be applied to property values as well as to elements of the graph. All of the schema could be captured in a graph, much in the same way that Java provides reflection via a specific set of classes. Schema access and mutation operations could thus be expressed in Gremlin, must in the same way that relational databases provide a set of tables that serves the same purpose there. Vendors would provide (full or partial) implementations of this API using existing extensibility mechanisms (e.g. strategies to apply to schema traversals) plus new ones (e.g. a SchemaGraph API with a canonical set of operations). On Wed, May 20, 2015 at 10:52 AM, pieter-gmail <[email protected]> wrote: > Hi, > > This is to hear what the community thinks about tinkerpop auto capturing > schema information. > > Since labels, any tinkerpop graph has a schema and seeing that tinkerpop > captures every vertex and edge with its label it could transparently > maintain this in the db itself. > > It should add little to no overhead to capturing data as schemas change > seldom and are small compared to the actual data. > > There are may use cases for having the schema available as part of the > regular graph. > > * Natural place to attach further (non tinkerpop) info like acl, audit > rules, multiplicities, navigability > * Might enable code insight for gremlin. > * Store performance/analytic result. > * Easy for new users to understand any graph's schema > * Might facilitate gremlin optimization > ... > > I understand that may implementations have their own peculiar schema > requirements. However my idea is not to walk a path outside of tinkerpop's > own semantics. > > Besides all that there is something sweet about a graph > containing/managing its own meta data. > > Thanks > Pieter >
