6 ms·

I think if you're aiming for any sort of broad adoption (are you?), then you'll have to add... SQL. This may sound like heresy, but in practice the following l

by moe 14y ago

I think if you're aiming for any sort of broad adoption (are you?), then you'll have to add... SQL. This may sound like heresy, but in practice the following line is going to be a showstopper for most people: Peer.q("[:find ?entity :where [?entity :db/doc \"hello world\"]]", db); I don't want to learn a new query language. And I'll most certainly not even try to re-train my team on it. Maybe later I'll become curious about that fancy datalog-language to enable advanced features. But in the beginning, if you want my mindshare, you'd better spoon-feed me. Take this lesson from cassandra. They started out with Thrift and an extremely cumbersome query-interface, which fit the cassandra data-model perfectly but not the brains of the developers. Now recently they exposed their query-language as a SQL dialect, and suddenly cassandra is a joy to use. You should do the same. It will be a lossy abstraction. You'll need weird, non-standard constructs to accommodate the peculiarities of your model. Purists will cry in horror. BUT: It will look like SQL and roughly work like SQL. Everybody and their dog already knows SQL. People can jump in and bang out "select foo from bar ..." without thinking. People can re-use an entire galaxy of SQL-related tooling and knowledge that has evolved over decades. Most importantly: People can start with something they know and then adapt at their own pace to the great new things that your datastore enables. Don't underestimate this if you're aiming for the mainstream.

arohner 14y ago
I'm pretty sure SQL will be added to datomic over Rich Hickey's dead body, and that's a good thing IMO. There are already enough SQL databases in the world. rhickey isn't looking to make a 'me too' database, he's interested in improving the state of software development. SQL is a terrible language and needs to die. It's fine that we disagree, but don't tell the people who are convinced it's a bad idea that they need to 'join' the mainstream.
- moe 14y ago
  It's not about making a "SQL-Database". It's about providing an interface that resembles something people are familiar with and that can be reasonably fluently typed in a REPL without breaking fingers. Just like Cassandra did with CQL and hbase does with HQL. SQL-syntax just happens to have stood the test of time for this kind of application. SQL is a terrible language No disagreement here. Just out of curiosity, what would you call this language then: [:find ?entity :where [?entity :db/doc \"hello world\"]]?
  - kleiba 14y ago
    Just out of curiosity, what would you call this language then: [:find ?entity :where [?entity :db/doc \"hello world\"]]? What exactly do you see as the problem with this example? Or with SQL for that matter? Honestly, I'm interested in what your criticism is. Is it the syntax?
    - moe 14y ago
      Yes, the syntax (or lack thereof, whichever you prefer). Obviously I'm not entitled to tell anyone how to design their databases. I'm just saying there's good reasons why so many DBs stick to a SQL-like syntax, and that is because the alternatives are usually worse (think: familiarity, tooling, scripting, REPL, etc.). For example, using the MongoDB REPL, which is probably close to what a datalog-REPL would look like, is rather painful. This may all be a non-issue when a LISP-language is exclusively used on the client-side. That query-style probably just snaps in naturally there (I don't know lisp). But if the database is supposed to be general purpose, accessed with lesser languages, scripted, quickly fixed by half-drunk humans at 4am in a REPL... then it certainly matters to have a sane intermediate lingo. Otherwise, at the least, every client-platform is going to invent their own. I think the example of Cassandra is really a good one to study. They went through an interesting learning-process that seems very applicable here. Edit: Please see my other comment above. It seems I have misunderstood the project goals and this is in fact not meant to become a general purpose DB. Under that premise my concerns obviously don't apply...
      - weavejester 14y ago
        Datomic is, as far as I'm aware, a general purpose database. What it isn't designed to be is a familiar database. SQL is what people are familiar with, and even some NoSQL databases have distinctly SQL-inspired query languages (e.g. SimpleDB). The problem is that SQL is a godawful query language, and if we want to do better we need to do something different, and therefore unfamiliar. SQL tries to look like natural language, which has resulted in a syntax is complex, inconsistent and monolithic, just like the language it tries to imitate. If we want a syntax that is simple, consistent and modular we need to throw away the idea that a query needs to read like English.
drcode 14y ago
Knowing the guys on the development team for datomic, I think their #1 concern is to produce a highly reliable and well-designed system. Also, they are big on developing systems that are very modular, and since datomic is built on Lisp, adding a SQL frontend would certainly be very easy (like a weekend project.) I'm sure once these guys have higher priority features addressed, you'll see a SQL feature as well (if folks from the clojure community don't beat them to it and create it first.)
- espeed 14y ago
  Davy Suvee created a Dataomic Blueprints implementation (http://datablend.be/?p=1641 http://datablend.be/?p=1641) so you can run Gremlin (https://github.com/tinkerpop/gremlin/wiki https://github.com/tinkerpop/gremlin/wiki) queries on it.

by moe 14y ago

arohner 14y ago

I'm pretty sure SQL will be added to datomic over Rich Hickey's dead body, and that's a good thing IMO. There are already enough SQL databases in the world. rhickey isn't looking to make a 'me too' database, he's interested in improving the state of software development. SQL is a terrible language and needs to die. It's fine that we disagree, but don't tell the people who are convinced it's a bad idea that they need to 'join' the mainstream.

moe 14y ago
It's not about making a "SQL-Database". It's about providing an interface that resembles something people are familiar with and that can be reasonably fluently typed in a REPL without breaking fingers. Just like Cassandra did with CQL and hbase does with HQL. SQL-syntax just happens to have stood the test of time for this kind of application. SQL is a terrible language No disagreement here. Just out of curiosity, what would you call this language then: [:find ?entity :where [?entity :db/doc \"hello world\"]]?
- kleiba 14y ago
  Just out of curiosity, what would you call this language then: [:find ?entity :where [?entity :db/doc \"hello world\"]]? What exactly do you see as the problem with this example? Or with SQL for that matter? Honestly, I'm interested in what your criticism is. Is it the syntax?
  - moe 14y ago
    Yes, the syntax (or lack thereof, whichever you prefer). Obviously I'm not entitled to tell anyone how to design their databases. I'm just saying there's good reasons why so many DBs stick to a SQL-like syntax, and that is because the alternatives are usually worse (think: familiarity, tooling, scripting, REPL, etc.). For example, using the MongoDB REPL, which is probably close to what a datalog-REPL would look like, is rather painful. This may all be a non-issue when a LISP-language is exclusively used on the client-side. That query-style probably just snaps in naturally there (I don't know lisp). But if the database is supposed to be general purpose, accessed with lesser languages, scripted, quickly fixed by half-drunk humans at 4am in a REPL... then it certainly matters to have a sane intermediate lingo. Otherwise, at the least, every client-platform is going to invent their own. I think the example of Cassandra is really a good one to study. They went through an interesting learning-process that seems very applicable here. Edit: Please see my other comment above. It seems I have misunderstood the project goals and this is in fact not meant to become a general purpose DB. Under that premise my concerns obviously don't apply...
    - weavejester 14y ago
      Datomic is, as far as I'm aware, a general purpose database. What it isn't designed to be is a familiar database. SQL is what people are familiar with, and even some NoSQL databases have distinctly SQL-inspired query languages (e.g. SimpleDB). The problem is that SQL is a godawful query language, and if we want to do better we need to do something different, and therefore unfamiliar. SQL tries to look like natural language, which has resulted in a syntax is complex, inconsistent and monolithic, just like the language it tries to imitate. If we want a syntax that is simple, consistent and modular we need to throw away the idea that a query needs to read like English.

drcode 14y ago

Knowing the guys on the development team for datomic, I think their #1 concern is to produce a highly reliable and well-designed system. Also, they are big on developing systems that are very modular, and since datomic is built on Lisp, adding a SQL frontend would certainly be very easy (like a weekend project.) I'm sure once these guys have higher priority features addressed, you'll see a SQL feature as well (if folks from the clojure community don't beat them to it and create it first.)

espeed 14y ago
Davy Suvee created a Dataomic Blueprints implementation (http://datablend.be/?p=1641 http://datablend.be/?p=1641) so you can run Gremlin (https://github.com/tinkerpop/gremlin/wiki https://github.com/tinkerpop/gremlin/wiki) queries on it.