On Tue, Nov 30, 2010 at 12:00 PM, LauJensen wrote:
> @Janico:
>
> Since we allow strings as arguments to most functions, I think you
> could simple express it like so:
>
> clojureql.core> (defn st-intersects [loc poly]
> (format "ST_Intersects(%s,
> ST_GeographyFromText('SRID=
@Brenton,
Thanks a lot for the vote of confidence :) I will do my best to try
and make some kind of elegant design solution for this. Your
suggestions are great!
@Janico:
Since we allow strings as arguments to most functions, I think you
could simple express it like so:
clojureql.core> (defn st
First of all, thank you for this awesome library.
I'm experimenting with ClojureQL for accessing Postgis, the spacial
extender for Postgres. To improve the ClojureQL for this use case, it
would be useful to have a way to add custom predicates. For example to
find all places whose location column i
Lau,
I agree that it is a lot of work and no one person can do it all well.
I think that the main thing that needs to happen at this point is that
you, as the brains behind ClojureQL, should spend a little time
thinking about the best way for people to contribute back end
implementations. Maybe th
There's some valuable food for thought in this thread.
My major problem with support various backends is the amount of work
thats involved. Every single backend needs to play nice with all the
primitives defined in Relational Algebra and that are implemented in
ClojureQL. I believe that the SQL92
Allowing implementation-specific and optimized SQL only via strings
and not via a mechanism within ClojureQL allows its use in specific
applications but effectively prevents use for libraries and
frameworks. Indirect use of ClojureQL could yield unacceptable
performance with no elegant fix.
On N
Database dialect independence may be a useful thing to have for
ClojureQL, so that users can work based on intent rather than syntax.
Consider something like this (just an idea):
;; by default in ClojureQL
;; make-sql92-handler is a factory fn for a protocol
(def *dialect-handler* (make-sql92-hand
On Nov 25, 8:28 am, LauJensen wrote:
> ClojureQL:
>
> (defn oracle-take
> [tname limit]
> (-> (table (str "(SELECT ROW_NUMBER() OVER (ORDER BY key ASC)"
> " AS rownumber,columns"
> " FROM " (to-tablename tname) ")"))
> (select (where (<= :rownumber lim
Hi Brenton,
Yes the OFFSET/LIMIT syntax differs from backend to backend. However
in some instances (like MySQL/PostgreSQL) they have ensured
compatability so that the same statement will run on several DBs
although the syntax might not be considered 'native'. For something
like Oracle there actual
> ClojureQL does not take the backend in to account. This is the one
> feature from the old CQL that I didn't want to carry over because it
> would be impossible for me to cater to all backends. If you hit
> specific problems, let me know and I'll see what we can do.
>
> We adhere to SQL92 and test
No problem Luke.
ClojureQL does not take the backend in to account. This is the one
feature from the old CQL that I didn't want to carry over because it
would be impossible for me to cater to all backends. If you hit
specific problems, let me know and I'll see what we can do.
We adhere to SQL92 a
Thanks... I think I do see the benefit. I'll certainly give it a try
and see if I can get the feel of it.
One question... You say it generates optimized SQL. Does it take the
DBMS into account? I know the performance profiles of various SQL
idioms vary widely between MySQL and Oracle, for example
Hi Luke,
Thanks!
Initially CQL0.1 was motivated by "everything in Clojure" which was
the driving design principle behind the first version of CQL. When
I scrapped that project (for reasons you can read on my blog) I
instead turned my attention towards Relational Algebra as this
gives you unique w
Lau,
This is really impressive, and I can't wait to experiment with it.
That said, I'm curious as to what good use cases for this would be,
and what it's motivation is. SQL is already a highly specialized DSL
for slinging around relational data that most developers are already
pretty good with. I
@Wilson,
Normally I release the jar to clojars when I implement some major
change
of interest to the public, but the compiler above didn't not get
released
due to forgetfulness on my part!
I was reworking the predicate compiler into a very fancy record which
does automated parameterization of all
On Tue, Nov 23, 2010 at 5:34 AM, LauJensen wrote:
> And finally, I've just refurbished the compiler so that its not a
> 25 line beast of a recursive machine that automatically spawns
> subselects for aggregates, limit/offset and predicates:
>
> cql.core> (to-sql (-> (table {} :users)
>
@Mark: Thanks! :)
@Jeff: Thanks a lot. Link is fixed now.
@Sam: Thanks!
@James: Wow - I should put that in my resume, thanks a lot !
@Mark E:
Half right.
ClojureQL has a major focus on queries as they are the largest
part of our interaction with databases. However it piggy-backs
on contrib.sql
ClojureQL is all about queries, right? As far as I can tell, it provides no
abstraction for creating tables, specifying indices, etc., correct?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.
I've just been playing around with ClojureQL, and I'm very impressed
at how clean, elegant and idiomatic the syntax is. So far this is the
best SQL library I've come across - for any language.
- James
On 18 November 2010 19:10, LauJensen wrote:
> Hi gents,
>
> For those of you who have followed
Looks really good. Great work,
Sam
---
http://sam.aaron.name
On 18 Nov 2010, at 19:10, LauJensen wrote:
> Hi gents,
>
> For those of you who have followed the development
> of ClojureQL over the past 2.5 years you'll be excited
> to know that ClojureQL is as of today being released
> as 1.0.0
Looks great, I'm giving it a try now. FYI, the github link in your
post is the private URL so it won't work for anyone but you.
-Jeff
On Nov 18, 8:10 pm, LauJensen wrote:
> Hi gents,
>
> For those of you who have followed the development
> of ClojureQL over the past 2.5 years you'll be excited
On Nov 18, 1:10 pm, LauJensen wrote:
> Hi gents,
>
> For those of you who have followed the development
> of ClojureQL over the past 2.5 years you'll be excited
> to know that ClojureQL is as of today being released
> as 1.0.0 beta1.
>
> That means that the significant primitives from Relational
On 19 November 2010 06:10, LauJensen wrote:
> Hi gents,
>
> For those of you who have followed the development
> of ClojureQL over the past 2.5 years you'll be excited
> to know that ClojureQL is as of today being released
> as 1.0.0 beta1.
>
> That means that the significant primitives from Rela
Hi gents,
For those of you who have followed the development
of ClojureQL over the past 2.5 years you'll be excited
to know that ClojureQL is as of today being released
as 1.0.0 beta1.
That means that the significant primitives from Relational
Algebra are all in place and functional. The document
24 matches
Mail list logo