Marko,

Thanks for the link, it's obviously very relevant to what we're doing!
We've talked a ton about trying to solve some of the problems it looks like
k-reef was designed to, but weren't quite ambitious enough :)

We have an alpha release coming up- would you be interested in seeing what
we have?

--
Matt Luongo
Co-Founder, Scholr.ly


On Mon, Dec 5, 2011 at 12:30 PM, Marko Rodriguez <okramma...@gmail.com>wrote:

> Hey,
>
> Matt: This isn't related to this thread, but I noticed you are from
> Scholar.ly. I thought you might like this:
>
>        http://arxiv.org/abs/0905.1594
>
> Go Canucks!,
> Marko.
>
> http://markorodriguez.com
>
> On Dec 4, 2011, at 12:58 AM, Matt Luongo wrote:
>
> > Well, I had already started writing this before I saw your response- so,
> if
> > you do decide down the road that you care more about immediate
> performance
> > than keeping DRY... ;)
> >
> >    g.setMaxBufferSize(0) //turn on tx handlings
> >    g.startTransaction()
> >
> >    found = g.idx('node_auto_index')[[name:'uni...@example.com']].count()
> >    if (found == 0) {
> >        //other custom create code could go here, and/or have vars passed
> > through json
> >        results = g.addVertex([:])
> >    } else {
> >        results = g.idx('node_auto_index')[[name:'uni...@example.com
> > ']].count().next()
> >    }
> >
> >    g.stopTransaction(TransactionalGraph.Conclusion.SUCCESS)
> >    g.setMaxBufferSize(1)
> >
> >    results
> >
> > would be something like the Groovy you'd use.
> >
> > I don't blame you for wanting to avoid the many choices available right
> now
> > - I'm already generating Javascript for traversal pruning and templating
> > Gremlin, all in the name of performance...
> >
> > --
> > Matt Luongo
> > Co-Founder, Scholr.ly
> >
> >
> >
> > On Sun, Dec 4, 2011 at 2:38 AM, dnagir <dna...@gmail.com> wrote:
> >
> >> Thanks Matt.
> >>
> >> Yeah. I think the transaction API is in making. Would be great addition.
> >>
> >> The server-side plugin will definitely work, but I personally prefer to
> >> use one way of doing things. At least until I will start speaking neo4j
> >> natively :)
> >>
> >> Cheers,
> >> Dmytrii
> >> http://www.ApproachE.com
> >>
> >>
> >> On 04/12/2011, at 6:35 PM, mhluongo [via Neo4j Community Discussions]
> >> wrote:
> >>
> >>> I've run into this problem, and resorted to using the Gremlin/Groovy
> over
> >>> REST (via the server-included plugin).
> >>>
> >>> There really isn't a way to transactionally express a conditional (or
> >>> get-or-create) like that over the vanilla REST API, though I'm sure
> it's
> >> in
> >>> the works.
> >>>
> >>> --
> >>> Matt Luongo
> >>> Co-Founder, Scholr.ly
> >>>
> >>>
> >>>
> >>> On Thu, Dec 1, 2011 at 5:45 PM, dnagir <[hidden email]> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I wonder what's the best way to do something similar to unique
> >> constraints
> >>>> in RDBMS.
> >>>>
> >>>> For example, user registration requires that the user's email to be
> >> unique.
> >>>>
> >>>> Working over in Ruby over REST API, how do you achieve this?
> >>>>
> >>>> I assume I need an auto-index on email property of User nodes. Then
> >> query
> >>>> it
> >>>> to check the property.
> >>>>
> >>>> But how can I make it transactional? So that I am sure that between
> >>>> querying
> >>>> and inserting the node, no similar has been inserted.
> >>>>
> >>>> The transactional part better applies to reservation instead of user
> >>>> creation. But you get the point.
> >>>>
> >>>> Cheers.
> >>>>
> >>>> --
> >>>> View this message in context:
> >>>>
> >>
> http://neo4j-community-discussions.438527.n3.nabble.com/Unique-constraint-and-transaction-over-REST-tp3553148p3553148.html
> >>>> Sent from the Neo4j Community Discussions mailing list archive at
> >>>> Nabble.com.
> >>>> _______________________________________________
> >>>> Neo4j mailing list
> >>>> [hidden email]
> >>>> https://lists.neo4j.org/mailman/listinfo/user
> >>>>
> >>> _______________________________________________
> >>> Neo4j mailing list
> >>> [hidden email]
> >>> https://lists.neo4j.org/mailman/listinfo/user
> >>>
> >>>
> >>> If you reply to this email, your message will be added to the
> discussion
> >> below:
> >>>
> >>
> http://neo4j-community-discussions.438527.n3.nabble.com/Unique-constraint-and-transaction-over-REST-tp3553148p3558628.html
> >>> To unsubscribe from Unique constraint and transaction over REST, click
> >> here.
> >>> NAML
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://neo4j-community-discussions.438527.n3.nabble.com/Unique-constraint-and-transaction-over-REST-tp3553148p3558630.html
> >> Sent from the Neo4j Community Discussions mailing list archive at
> >> Nabble.com.
> >> _______________________________________________
> >> Neo4j mailing list
> >> User@lists.neo4j.org
> >> https://lists.neo4j.org/mailman/listinfo/user
> >>
> > _______________________________________________
> > Neo4j mailing list
> > User@lists.neo4j.org
> > https://lists.neo4j.org/mailman/listinfo/user
>
> _______________________________________________
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to