5 ms·

As an existence proof: before the acquisition we built an ANSI SQL database and a wire-compatible clone of the MongoDB API. I see no reason you wouldn't be abl

As an existence proof: before the acquisition we built an ANSI SQL database and a wire-compatible clone of the MongoDB API. I see no reason you wouldn't be able to implement Datastore. In fact here's a public source claiming that Firestore (which I believe is its successor) is implemented on top of Spanner: https://www.theregister.co.uk/2017/10/04/google_backs_up_firebase_with_a_second_realtime_data_store/ https://www.theregister.co.uk/2017/10/04/google_backs_up_fir...

X-Istence 8y ago
Is the wire-compatible clone of the MongoDB API available?
- wwilson 8y ago
  It doesn't look like Apple open-sourced the Document Layer, which is a slight bummer. But I echo what Dave said below: what we got is incredible, let's not get greedy! Also TBH now that I don't have commercial reasons to push interop, if I write another document database on top of FDB, I doubt I'd make it Mongo compatible. That API is gnarly.
  - chx 8y ago
    > That API is gnarly. Out of the many MongoDB criticisms, this one is valid. This https://www.linkedin.com/pulse/mongodb-frankenstein-monster-nosql-databases-john-de-goes/ https://www.linkedin.com/pulse/mongodb-frankenstein-monster-... article is quite right about it (note: endorsing the article does not mean I endorse its author by far). Other than that, they totally did a fake it until you make it with MongoDB 3.4 passing Jepsen a year ago and MongoDB BI 2.0 containing their own SQL engine instead of wrapping PostgreSQL.
    - aeorgnoieang 8y ago
      What specifically are you trying to avoid endorsing about the author of the LinkedIn post to which you linked? I couldn't find anything from a cursory web search.
      - mst 8y ago
        He runs lambdaconf, and refused to disinvite a speaker who many people felt shouldn't be permitted to speak because of his historical non-technical writings. (I've tried to keep the above as dry as possible to avoid dragging the arguments around this situation into this thread - and I suspect the phrasing of the previous comment was also intended to try and avoid that, so let's see if we can keep it that way, please)
      - chx 8y ago
        You could try adding controversy to the author name and searching then. As mst correctly notes, I am trying to avoid reigniting said controversy while indicating my distaste.
  - itp 8y ago
    > That API is gnarly. The Will Wilson I remember was not prone to such understatement. That API (and the corresponding semantics) was a nightmare.
  - tjb1982 8y ago
    I was pretty bummed not see that, myself
rthomas900 8y ago
If I recall correctly, the "SQL layer" you had in FDB before the Apple acquisition was a nice proof of concept, but lacked support for many features (joins in SELECT, for example). Is the SQL layer code from that time available anywhere to the public? (I'm not seeing it in the repo announced by OP.)
- tjb1982 8y ago
  I used to work there. The SQL layer was capable of actually the majority of SQL features including joins, etc. We had an internal rails app that we used to dog-food for performance monitoring, etc. I used to work on the document layer, and was sad to see it wasn't included here.
- rthomas900 8y ago
  Perhaps it's this? https://github.com/jaytaylor/sql-layer https://github.com/jaytaylor/sql-layer
  - zwily 8y ago
    That has FoundationDB dependencies that don’t exist in the apple repo (SQL Parser, JDBC Driver, etc)
edwinyzh 8y ago
I hope this question doesn't feel too dump, but is it possible to implement a SQL Layer using SQLite's Virtual Table mechanism and leverage all foundationdb's features?

X-Istence 8y ago

Is the wire-compatible clone of the MongoDB API available?

wwilson 8y ago
It doesn't look like Apple open-sourced the Document Layer, which is a slight bummer. But I echo what Dave said below: what we got is incredible, let's not get greedy! Also TBH now that I don't have commercial reasons to push interop, if I write another document database on top of FDB, I doubt I'd make it Mongo compatible. That API is gnarly.
- chx 8y ago
  > That API is gnarly. Out of the many MongoDB criticisms, this one is valid. This https://www.linkedin.com/pulse/mongodb-frankenstein-monster-nosql-databases-john-de-goes/ https://www.linkedin.com/pulse/mongodb-frankenstein-monster-... article is quite right about it (note: endorsing the article does not mean I endorse its author by far). Other than that, they totally did a fake it until you make it with MongoDB 3.4 passing Jepsen a year ago and MongoDB BI 2.0 containing their own SQL engine instead of wrapping PostgreSQL.
  - aeorgnoieang 8y ago
    What specifically are you trying to avoid endorsing about the author of the LinkedIn post to which you linked? I couldn't find anything from a cursory web search.
    - mst 8y ago
      He runs lambdaconf, and refused to disinvite a speaker who many people felt shouldn't be permitted to speak because of his historical non-technical writings. (I've tried to keep the above as dry as possible to avoid dragging the arguments around this situation into this thread - and I suspect the phrasing of the previous comment was also intended to try and avoid that, so let's see if we can keep it that way, please)
    - chx 8y ago
      You could try adding controversy to the author name and searching then. As mst correctly notes, I am trying to avoid reigniting said controversy while indicating my distaste.
- itp 8y ago
  > That API is gnarly. The Will Wilson I remember was not prone to such understatement. That API (and the corresponding semantics) was a nightmare.
- tjb1982 8y ago
  I was pretty bummed not see that, myself

rthomas900 8y ago

If I recall correctly, the "SQL layer" you had in FDB before the Apple acquisition was a nice proof of concept, but lacked support for many features (joins in SELECT, for example). Is the SQL layer code from that time available anywhere to the public? (I'm not seeing it in the repo announced by OP.)

tjb1982 8y ago
I used to work there. The SQL layer was capable of actually the majority of SQL features including joins, etc. We had an internal rails app that we used to dog-food for performance monitoring, etc. I used to work on the document layer, and was sad to see it wasn't included here.
rthomas900 8y ago
Perhaps it's this? https://github.com/jaytaylor/sql-layer https://github.com/jaytaylor/sql-layer
- zwily 8y ago
  That has FoundationDB dependencies that don’t exist in the apple repo (SQL Parser, JDBC Driver, etc)

edwinyzh 8y ago

I hope this question doesn't feel too dump, but is it possible to implement a SQL Layer using SQLite's Virtual Table mechanism and leverage all foundationdb's features?