EXPath: MongoDB Module?

[Christian Grün]

Dear all,

As you may have seen, Dannes Wessels presented Mongrel, an XQuery
Module, on the eXist-db pre-conference [1]. We implemented a similar
module a short while ago, and Zorba did so as well two years ago [2].

I talked to Dannes, and he would also be interested in contributing to
a joint EXPath module, based on XQuery 3.1 [3]. Would some of you be
interested in having such a module as well?

All the best,
Christian

[1] https://www.youtube.com/watch?v=liGP7f9E5xw
[2] http://archive.xmlprague.cz/2013/presentations/Bringing_the_NoSQL_Datastores_into_an_XQuery_Playground.pdf
[3] https://github.com/dizzzz/Mongrel/issues/35#issuecomment-75781376

[Hans-Juergen Rennau]

Christian, I would be ardently interested. I think it is of strategic importance to broaden the scope of data sources available to XPath/XQuery. And this with two possible goals: (a) apply XQuery and its peculiar strengths to the contents of existing infrastructure, that is, to content existent in our environments, indepently of XML technologies; (b) leverage non-XML technologies to assist in the management of large XML collections, e.g. by using non-XML in order to store XML documents as blobs, or to store XML document references (e.g. URIs), and to associate those blobs or references with queryable information about those XML resources.

Therefore it is both SQL access and NoSQL access which I hope the EXPath group to take care of.

Cheers,

Hans-Juergen

--
You received this message because you are subscribed to the Google Groups "EXPath" group.
To unsubscribe from this group and stop receiving emails from it, send an email to expath+unsub...@googlegroups.com.
To post to this group, send email to exp...@googlegroups.com.
Visit this group at http://groups.google.com/group/expath.
For more options, visit https://groups.google.com/d/optout.

[Adam Retter]

The problem I have with a mongo module is that it is very specific to one system. I would rather see more general purpose modules. For example, if my xmldb suddenly grew to support native json... is it still mongo, I don't think so.

I would rather see a module focused on access to json data sources (or better yet, with a wider focus).

To unsubscribe from this group and stop receiving emails from it, send an email to expath+un...@googlegroups.com.

[Jonathan Robie]

I would.

Jonathan

[Hans-Juergen Rennau]

Adam, your objection certainly makes sense. But perhaps here are two different perspectives possible - an API offering abstractions and generalizations, and an API which is a plain, straightforward, one-to-one gateway to a particular technology. The granularity and sope of Java APIs can be our guide - if two NoSQL databases have two different APIs, it makes sense to add two modules to XQuery.

I think of the SQL module offered by BaseX. It is plain access to RDBMS, you use SQL queries and you receive SQL responses, only XMLified in the obvious way. All very plain, and very useful - it opens the door to a technology. More such doors, please.

I would like to have a similar, plain gateway to MongoDb, and plain gateways to other NoSQL databases as well. Each of them is an offering of new possibilities.

Hans-Juergen

[William Candillon]

Hello gang,

Our MongoDB module documentation is available at
http://www.28.io/documentation/latest/modules/connectors/mongodb-module/

William


On Tue, Feb 24, 2015 at 11:13 PM, 'Hans-Juergen Rennau' via EXPath

[Adam Retter]

On 24 February 2015 at 22:13, Hans-Juergen Rennau <hre...@yahoo.de> wrote:
> Adam, your objection certainly makes sense. But perhaps here are two
> different perspectives possible - an API offering abstractions and
> generalizations, and an API which is a plain, straightforward, one-to-one
> gateway to a particular technology. The granularity and sope of Java APIs
> can be our guide - if two NoSQL databases have two different APIs, it makes
> sense to add two modules to XQuery.

IMHO it only makes sense if the APIs are so different that you cannot
create an abstraction, or if such an abstraction would so dilute the
ability to perform the intended purpose that it was unfit.

Obviously I am not going to stop anyone if they really want to spend
their time on this, I was rather asking if there was not a way to
abstract this, that would mean 1 spec for N implementations.

--
Adam Retter

eXist Developer
{ United Kingdom }
ad...@exist-db.org
irc://irc.freenode.net/existdb

[Christian Grün]

In general, a common API for different NoSQL or JSON stores sounds enticing.

My experience with other NoSQL systems is limited; however, the
impression I had so far is that the systems are simply too
heterogeneous to really bring them together, and to still do justice
to each system. In the worst case, this intent could lead to an API
that only contains a connect() and close() function, as we can't even
assume that each system provides something like a "database",
"collection", or even a query. Things may be easier for key/value
stores, but even then, people might tend to use the systems' REST
interfaces if the common API does not provide enough features.

The MongoDB driver we currently have in mind is inspired by the
existing MongoDB APIs [1]. I think the major challenge will be to
figure out what basic subset we want to support in the first run, and
if the resulting spec can be extended to support all missing features.

[1] http://docs.mongodb.org/ecosystem/drivers/

[Hans-Juergen Rennau]

Fully agree with Christian's view about the difficulties of an API covering more than one NoSQL database.

Concerning the challenge to "figure out a basic subset we want to support in the first run", this thought. Perhaps it is an option to restrict the initial API version to CRUD operations [1]  and regard the management of the collections (creation, configuration etc.) as (for the time being) out of scope. To take the view that MongoDB collections simply exist and XQuery code should be enabled to retrieve and update their content. Perhaps this might lead to a small and focused API for a start?

Hans-Juergen

[1] http://docs.mongodb.org/v2.6/MongoDB-crud-guide.pdf

> To unsubscribe from this group and stop receiving emails from it, send an email to expath+unsub...@googlegroups.com.

> To post to this group, send email to exp...@googlegroups.com.
> Visit this group at http://groups.google.com/group/expath.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "EXPath" group.

To unsubscribe from this group and stop receiving emails from it, send an email to expath+unsub...@googlegroups.com.

[Joern Turner]

My 2 cents,

i would also support Christian here and furthermore wouldn't even consider looking for an abstraction in the first place. This would require a fair good overview and understanding of the different JSON stores, find a consens for the API and could too likely stop the engagement in an early phase due to the burden of priliminary conceptual work.

In my experience it's far better to make it work with one store first (Mongo) and afterwards look for abstractions as soon as the interest for another store comes up (if ever). Mongo is reasonably prominent in that field so we can see if there's really the broad interest for such an hybrid (which i think there is). If our expectations are not met and only 2 or 3 people use such a thing the lost effort was still worth the try ;)

To unsubscribe from this group and stop receiving emails from it, send an email to expath+un...@googlegroups.com.