graph db and query interface as GO library about cayley

[barakmich]

Adding myself to this as well.

Clearly we agree a more helpful high-level API is worth doing. Thoughts on this are wide open!

I'm not sure breaking the repository apart is necessary/wise. You can already go get the necessary components. I'm not sure if dependencies are thus transitive, but go get still covers you. Either way, though, you'll need some store one way or another.

[kortschak]

Importing store packages would be necessary in such a system anyway, even if only as a blank import for registration. I don't see that any significant restructuring is necessary to achieve what is being asked for here; once a Go query API is written, you import that and the relevant store package and use the code, go get will pull all the necessary dependencies transitively.

[bsr203]

Thanks. I agree it is go gettable now, and can just get the sub component needed.
Current design is well abstracted and I could run REPL after removing UI/appengine/mongo/leveldb/http/.. . I was more concerned with importing 3rd party driver libraries (mgo, levelgo,) which may grow in the future with additional supported backends. If I don't use REPL / Gremlin / MQL, bust just core and memstore, I may import the core (graph + GO API), and a store. Is it possible to do that? thanks again

[kortschak]

We have discussed extending store registration. In the long term this would allow decoupling of stores from logic and would give you the behaviour you want.

[pbnjay]

In thinking about attacking #74, I think it may be useful to build a graph.Query object to wrap much of this. Then the gremlin and MQL parsers/output can share more code at least.

[barakmich]

Actually, @pbnjay, I'm going to merge this issue into #64 -- which is where I think something like graph.Query may come in (as the original bit about separate packages and go gettable components is now done, also thanks to you)

[barakmich]

Merging into #64