4 ms·

It depends on which direction you approach the problem from. Are people approaching their database from the stand point of pure relational algebra? Or are they

by ibdknox 15y ago

It depends on which direction you approach the problem from. Are people approaching their database from the stand point of pure relational algebra? Or are they approaching it from the stand point of "this is how SQL allows me to interact with my data"? In my experience, it's very definitely the latter. As such, providing an interface that attempts to model relational algebra explicitly and treats SQL as an implementation detail doesn't cleanly map to how people actually think about the problem. This makes the abstraction obtuse and significantly more complex. At the simplest possible level, when I go to look up "how do I do x in postgres," the answer will be in SQL, not relational algebra. Why force users to remap the way they think about the problem? Moreover, what do we actually gain by trying to map relational algebra to SQL? Why not work in SQL directly? That's what Korma does. CQL generates lots of subselects in places that they aren't needed. I'm not looking at it from the stand point of the time it takes to generate a query, but instead how long it takes the generated queries to run. Subselects are slow. Generating queries that use lots of them is going to be slower than a system that doesn't. Could CQL better compile down to SQL? Probably, but it doesn't currently. In terms of expressiveness, both allow for composition of SQL components over time, which definitely beats SQL itself. I would argue that Korma has an edge over CQL here simply because it allows you to directly craft the queries to operate exactly the way you want.

ibdknox 15y ago
I should also point out that there's no reason these two can't exist together. When you really think about it, Korma is like ring for SQL and enables a host of higher level abstractions to be built on top of it. To that end, it would actually be fairly easy to build CQL on top of Korma :)
- tensor 15y ago
  The issue I have here is that I think at their core, both solve the same problem in nearly the same way. The use of SQL-like syntax versus CQLs more mathematical terms like project is a valid point, but ultimately doesn't at all change the abstraction. SQL itself is largely just a different syntax for relational calculus. I suppose I'm seeing another Lein vs. Cake situation here and feel that it would be nice if efforts were concentrated. Both CQL and Korma need to make some changes to make fragments composable. The only really interesting difference is the issue of subselects and why CQL generates a lot of them in it's translation to SQL. From a theoretical standpoint, subselects can often be rewritten as joins and many databases do this as part of their query compilation process. It doesn't seem like an unfixable problem. For example: (-> (select* "user") (fields :id :username) (where {:email [like "*@gmail.com"]}))) This can be written in CQL (I think): (def user (table db :user)) (-> (select user) (project [:id :username]) (where (like :email "*@gmail.com"))) So the difference is only renaming project to fields? Niether keywords are in SQL. Other syntax differences like limit instead of take are similarly minor. It almost seems like you could just def some aliases and the two libraries would read nearly the same. It really feels like a part of Korma and ClojureQL should be the same library with the entities and has-one type relations built on top of it. Choice of keywords shouldn't be a massive stumbling block to collaboration, although the subselect problem in CQL should certainly be addressed. I do hear what you are saying, but I can't actually see it in the implementation. Edit: I don't mean to be overly critical. :) It's just that the two libraries seem so very similar to me!
  - ibdknox 15y ago
    If you look at their implementations, they're very different :) But as I said, they could converge - CQL fits nicely as a higher-level interface over Korma. And for what it's worth, I didn't build Korma for no reason... an awful lot of people have wanted an alternative to CQL. If for no other reason than to have something that is being really actively maintained.
    - tensor 15y ago
      That much is clear, and I think the differences are probably the interesting part. :) I'll try to set aside some time to look at the implementation details of the two libraries. My favorite blog post (not mine) discussing this is: http://thinkrevoactevo.blogspot.com/2011/11/sql-in-clojure.html http://thinkrevoactevo.blogspot.com/2011/11/sql-in-clojure.h... but it also does not address the fact that relational algebra and SQL selects are very closely related things. I think that there is a very nice theoretical issue hiding here realting to composable sql fragments. If I come to any interesting conclusions I'll message you. Part of my day job is writing a new type of query compiler, so this is an interesting topic to me.

by ibdknox 15y ago

ibdknox 15y ago

I should also point out that there's no reason these two can't exist together. When you really think about it, Korma is like ring for SQL and enables a host of higher level abstractions to be built on top of it. To that end, it would actually be fairly easy to build CQL on top of Korma :)

tensor 15y ago
The issue I have here is that I think at their core, both solve the same problem in nearly the same way. The use of SQL-like syntax versus CQLs more mathematical terms like project is a valid point, but ultimately doesn't at all change the abstraction. SQL itself is largely just a different syntax for relational calculus. I suppose I'm seeing another Lein vs. Cake situation here and feel that it would be nice if efforts were concentrated. Both CQL and Korma need to make some changes to make fragments composable. The only really interesting difference is the issue of subselects and why CQL generates a lot of them in it's translation to SQL. From a theoretical standpoint, subselects can often be rewritten as joins and many databases do this as part of their query compilation process. It doesn't seem like an unfixable problem. For example: (-> (select* "user") (fields :id :username) (where {:email [like "*@gmail.com"]}))) This can be written in CQL (I think): (def user (table db :user)) (-> (select user) (project [:id :username]) (where (like :email "*@gmail.com"))) So the difference is only renaming project to fields? Niether keywords are in SQL. Other syntax differences like limit instead of take are similarly minor. It almost seems like you could just def some aliases and the two libraries would read nearly the same. It really feels like a part of Korma and ClojureQL should be the same library with the entities and has-one type relations built on top of it. Choice of keywords shouldn't be a massive stumbling block to collaboration, although the subselect problem in CQL should certainly be addressed. I do hear what you are saying, but I can't actually see it in the implementation. Edit: I don't mean to be overly critical. :) It's just that the two libraries seem so very similar to me!
- ibdknox 15y ago
  If you look at their implementations, they're very different :) But as I said, they could converge - CQL fits nicely as a higher-level interface over Korma. And for what it's worth, I didn't build Korma for no reason... an awful lot of people have wanted an alternative to CQL. If for no other reason than to have something that is being really actively maintained.
  - tensor 15y ago
    That much is clear, and I think the differences are probably the interesting part. :) I'll try to set aside some time to look at the implementation details of the two libraries. My favorite blog post (not mine) discussing this is: http://thinkrevoactevo.blogspot.com/2011/11/sql-in-clojure.html http://thinkrevoactevo.blogspot.com/2011/11/sql-in-clojure.h... but it also does not address the fact that relational algebra and SQL selects are very closely related things. I think that there is a very nice theoretical issue hiding here realting to composable sql fragments. If I come to any interesting conclusions I'll message you. Part of my day job is writing a new type of query compiler, so this is an interesting topic to me.