NVM, it was my bad... I was starting transaction automatically, and that was creating problems...
On Tue, Dec 1, 2015 at 1:14 PM, Stephen Mallette <[email protected]> wrote: > Marvin, can you please elaborate? Is there a particular test that's > causing a problem where supportsSchema() could help make something easier > on your end? > > On Wed, Nov 25, 2015 at 2:37 PM, Marvin Froeder <[email protected]> wrote: > > > 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. > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > > >
