You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by Stephen Mallette <sp...@gmail.com> on 2015/12/01 01:14:55 UTC
Re: [DISCUSS] supportsSchema Feature
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 <ve...@gmail.com> 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 <sp...@gmail.com> 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 <ok...@gmail.com>
> > 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 <sp...@gmail.com>
> > > 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 <pi...@gmail.com>
> > > 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.
> > > >>>
> > > >>
> > > >>
> > >
> > >
> >
>
Re: [DISCUSS] supportsSchema Feature
Posted by Marvin Froeder <ve...@gmail.com>.
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 <sp...@gmail.com>
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 <ve...@gmail.com> 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 <sp...@gmail.com> 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 <okrammarko@gmail.com
> >
> > > 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 <spmallette@gmail.com
> >
> > > > 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 <pi...@gmail.com>
> > > > 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.
> > > > >>>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>