Re: [expath] EXPath: MongoDB Module?

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 ;)

On Wed, Feb 25, 2015 at 10:54 PM, 'Hans-Juergen Rennau' via EXPath <
expath@googlegroups.com> wrote:

> 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
>
>
>   Christian Grün <christian.gruen@gmail.com> schrieb am 13:48 Mittwoch,
> 25.Februar 2015:
>
>
> 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/
>
>
> On Wed, Feb 25, 2015 at 10:32 AM, Adam Retter <adam@exist-db.org> wrote:
> > On 24 February 2015 at 22:13, Hans-Juergen Rennau <hrennau@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 }
> > adam@exist-db.org
> > irc://irc.freenode.net/existdb
>
> >
> > --
> > 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+unsubscribe@googlegroups.com.
> > To post to this group, send email to expath@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+unsubscribe@googlegroups.com.
> To post to this group, send email to expath@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+unsubscribe@googlegroups.com.
> To post to this group, send email to expath@googlegroups.com.
> Visit this group at http://groups.google.com/group/expath.
> For more options, visit https://groups.google.com/d/optout.
>