agreed - not sure how we can easily generalize that even in read-only mode and not have it come out all dumpy like TP2 index management.
On Wed, Nov 25, 2015 at 1:28 PM, Marko Rodriguez <[email protected]> wrote: > Hi, > > I don't think we should specify a "schema," but if you need this for > better testing differentiation, then just a "true/false" supportsSchema. > > Marko. > > http://markorodriguez.com > > On Nov 25, 2015, at 10:54 AM, Stephen Mallette <[email protected]> > wrote: > > > i don't have anything in mind in particular, but i suppose the feature > > would in some ways be preparation for such an actual feature. right now, > i > > just want to make sure that tests are controlled properly and assert the > > right things if the graph supports coercing types to the types known in > the > > schema. it will just make the test suite more friendly. > > > > as for the actual feature of a schema abstraction, i guess that's a > > separate discussion. off the top of my head, just offering a way for the > > user to get a read-only view into a schema sounds like a good/easy sort > of > > start. of course, schema gets complex pretty fast even in that use case > as > > it brings with it the concept of indices and such. different providers > > will have different attributes and representation of their schema. we'd > > have to be so careful, so as to not make it so general and useless as > > indexing abstractions in TP2. > > > > Maybe I shouldn't name the feature related to "schema" to avoid > confusion - > > maybe it should more be about supportsTypeCoercion - though that seems a > > little too specific for the test cases i have in mind that are trouble > > areas. > > > > On Wed, Nov 25, 2015 at 12:41 PM, pieter <[email protected]> > wrote: > > > >> +1 > >> > >> What do you have in mind as a schema abstraction? > >> > >> On 25/11/2015 19:02, Stephen Mallette wrote: > >>> We don't have a schema abstraction yet in TinkerPop, but graph > providers > >> do > >>> support that capability. That capability can cause problems with the > >>> TinkerPop test suite as the test suite sometimes makes assumptions > about > >>> types based on the immediate test bases we have in two schemaless > graphs > >> of > >>> TinkerGraph and Neo4j - those assumptions tend to lead to problems. > >>> > >>> If we had a new Feature called supportsSchema() we would know if a > graph > >>> had that capability and we could write tests with different behaviors > for > >>> graph providers who have strong typing systems. > >>> > >>> Anyway, I've created an issue here that relates to this idea: > >>> > >>> https://issues.apache.org/jira/browse/TINKERPOP3-992 > >>> > >>> If there are no objections to supportsSchema() in the next 72 hours > >>> (Saturday, November 28, 2015 at 12pm), i'll assume lazy consensus and > >> move > >>> forward with that concept for 3.1.1-incubating. > >>> > >> > >> > >
