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-handler)) ;; somewhere in an app (binding [cql/*dialect-handler* (make-oracle-handler)] ;; do usual stuff ..) This kind of a structure may allow others to write dialect handlers for different databases as contrib and ClojureQL can stay as the composable core. Databases that do not support all of SQL-92 constructs can throw a FeatureNotAvailable exception when an unsupported intent is asked for. Regards, Shantanu On Nov 25, 12:28 pm, LauJensen <lau.jen...@bestinclass.dk> wrote: > 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 actually isnt a syntax for LIMIT so instead they do > something like > > SELECT * FROM ( > SELECT > ROW_NUMBER() OVER (ORDER BY key ASC) AS rownumber, > columns > FROM tablename > ) > WHERE rownumber <= n > > But as you can see it would be trivial to express this in terms of > 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 limit))) > (project ["*"]))) > > (to-sql (oracle-table :users 10)) > ["SELECT * FROM (SELECT ROW_NUMBER() OVER (ORDER BY key ASC) AS > rownumber,columns FROM users) WHERE (rownumber <= ?)" 10] > > From the outset it has been my ambition to make ClojureQL extremely > composable and as far as possible allow users to directly insert > strings into the query to allow for backend specific customization. > The entire design-plan of this customization is not yet thought out so > input is welcomed. To me, flexibility and leaving with the power to > the user is the key to wide adoption across various backends. > > Lau > > On Nov 24, 11:42 pm, Brenton <bashw...@gmail.com> wrote: > > > > > > > > > > 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 everything on MySQL and Postgres. If > > > you're in a situation where thats not good enough, its always possible > > > to supply part of your expression as a string. > > > Lau > > > Off the top of my head, I know that the LIMIT syntax for SQL Server is > > totally different. A lot of the apps that I write end up getting > > deployed using Oracle and SQL Server. If you plan for CQL to be widely > > used I think you will need to take backends into account. You don't > > need to implement them all yourself, but you should provide a way so > > that others can implement them when they need to. > > > Brenton -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
