One problem we had on orientDB is to have schemas + transactions. OrientDB supports both, but not together, it can't change schema inside a transaction.
May be this support schema flag could accommodate this scenario as well On Thu, 26 Nov 2015 08:18 Stephen Mallette <[email protected]> wrote: > 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. > > >>> > > >> > > >> > > > > >
