summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2013-09-29Remove `having` from the lsit of vars to pull into core (should have been on ↵Carlo Zancanaro
earlier commit).
2013-09-29Clear up the ambiguous field error messageCarlo Zancanaro
The ambiguous field error message used to specify that it was a case where multiple tables were present, but that's not always true. If you're trying to work on a query that has been "subqueried" then you'll also get the error (arguably that should have a different error message, but I'll come back to that later).
2013-09-29Remove the `having` function, incorporate into `select`Carlo Zancanaro
The `having` function duplicated the intended functionality of `select`, but in a bad way. It only applied to a restricted case, and its existence meant that `select` provided an escape-hatch with which we could cause some unexpected behaviour. By consolidating the two functions into `select` we remove the escape hatch as well as simplify the model. Selection on grouped queries may now introduce a new subquery, but only in situations where the behaviour is unpredictable (ie. selecting on non-grouped attributes).
2013-07-12A bunch of refactoring in the DSLCarlo Zancanaro
2013-07-12Remove some scrap code that got committed accidentallyCarlo Zancanaro
2013-07-12Handle parameter types in the compiler betterCarlo Zancanaro
The compiler handled them by converting most things to strings and embedding them in the query, but now I'm trying to put more of them in as query parameters. The advantage is that his handles types that might be database specific, or something. At the moment sequences are handled in the same way as before (with each element being a separate parameter), but this may be changed in future.
2013-07-12Assert in jdbc interface to fail early rather than do the wrong thingCarlo Zancanaro
When converting dotted fields to maps there's one possible case where it can do the wrong thing. This should now throw an AssertionError rather than silently doing the wrong thing.
2013-07-12Expose a few more helper functions in clojure-sql.coreCarlo Zancanaro
2013-07-12Add a rename helper to turn queries into "subobjects" in the result.Carlo Zancanaro
Essentially just prefixes a subobject name in front of all fields in a query, with a dot separating the new prefix and the original name.
2013-07-06Make `sort` able to take expressions rather than just table names.Carlo Zancanaro
2013-07-03Add fields to union/intersection result queriesCarlo Zancanaro
2013-07-01Change the condition for union compatible (require projections first)Carlo Zancanaro
2013-07-01Make fields compile in a deterministic order (necessary for union stuff)Carlo Zancanaro
2013-07-01Add union/intersection to the dslCarlo Zancanaro
2013-07-01Remove some extra code that was left sitting aroundCarlo Zancanaro
2013-07-01Make sure you never try to take a negative number of things!Carlo Zancanaro
2013-06-24Make dotted fields result in nested maps when queryingCarlo Zancanaro
So now something like this: (-> (table :users) (project {:id :user.id, :email :user.email, :person :person.id}) (join (-> (table :people) (project {:id :person.id, :first-name :person.first-name})))) will result in a map like this for each result: {:user {:id 1, :email "..."}, :person {:id 1, :first-name "..."}} Although I've just thought of an issue that will need to be detected where an error should be thrown. I'll deal with that now and commit it soon.
2013-06-23Make sort and group create subqueries to be correctCarlo Zancanaro
2013-06-23Make select take a map and compile to equality tests.Carlo Zancanaro
2013-06-23Misc changes.Carlo Zancanaro
2013-06-22Docstrings, one function call change, README update.Carlo Zancanaro
In the compiler there was one call to `table-name` which should have been `field-name`.
2013-06-21Docstrings, re-export from core better (with metadata)Carlo Zancanaro
2013-06-21Return records on update, return just a count on delete (jdbc)Carlo Zancanaro
2013-06-21Add take/drop, move jdbc stuff, document default of postgresCarlo Zancanaro
Add take and drop functionality to the queries, so now you can use the take and drop functions in a similar way to how they work on seqs in clojure. Move jdbc interface stuff into clojure-sql.jdbc, so if you're using jdbc you can include it yourself. (If you're not using jdbc then it shouldn't bother you). Given the default compilation target is actually postgres, document that.
2013-06-20Clean up, add an assertion.Carlo Zancanaro
2013-06-20Well, that didn't work. Whatever.Carlo Zancanaro
2013-06-20Fix updates, add "use-jdbc!" function to core.Carlo Zancanaro
2013-06-20Make core nicer, pass the "type" of query to executorsCarlo Zancanaro
2013-06-20Clean up the query deref, make insert!, update! and delete! workCarlo Zancanaro
2013-06-20Fix a stupid null-pointer exceptionCarlo Zancanaro
2013-06-20Fix compiling of n-ary operators (0 & 1 args), add operator aliasesCarlo Zancanaro
n-ary operators with no arguments would break everything (compiling to "()"). This should no longer be the case. Additionally, unary operators (ie. negation) now compile properly in the one arg case. Operator aliases allow us to change how we refer to things like the "~" regex operator in postgresql. At the moment it's aliased as "$". Additionally: booleans now compile to upper case.
2013-06-20A few small changes/fixes to join behaviour, and code cleanupCarlo Zancanaro
Fix compilation of cross joins. Remove the sort clauses on queries when they become subqueries in joins because then the sorting means nothing (although when take/drop stuff is added the sort will be relevant, so we'll see about that). Favour the left side of a join, which is mostly only relevant for the outer join case (and technically it's not quite right for full-outer joins, maybe, but I'll get to that later).
2013-06-17Rename sort-by, add grouping, refactor+fix some join stuffCarlo Zancanaro
`sort-by` is now called `sort`. This is just because I think it makes more sense and nothing more. Grouping has been added with `group` and `having`. They behave as you'd expect from SQL, except that joining with a table which has a `group` or `having` clause will move that query in as a subquery. I wasn't sure how else to ensure their composition, so this way maintains the semantics (which is the most important part) at the potential cost of some efficiency in performing the query. I'm not sure that there exists a more general solution. I would assume not. The join stuff has been fixed a bit (some valid renames were rejected as invalid) and standardised a bit (exceptions are now more similar). A bunch of things have been added to the join stuff as a result of the above grouping things, too. A bunch of changes all around, basically. The compiler has also had a few small changes made to it, and has been enhanced to support the grouping stuff.
2013-06-16Fix up some more join stuff, and a bit of sorting stuff.Carlo Zancanaro
2013-06-16Fix expression processing in the DSL, notably on vectorsCarlo Zancanaro
2013-06-16Bring the DSL back up to previous features, fix the compilerCarlo Zancanaro
It should generally be usable at this point. It should generate the queries correctly (including join order and stuff) and approximately properly do things. The type of join stuff still hasn't been finished, but if the code were left as-is it would still be possible to get whatever you wanted out of it, I think. Basically: lots of work has been done and we're approaching something more usable.
2013-06-13Starting a re-write of the DSL, to be followed by the compiler.Carlo Zancanaro
Flip around field/table aliases, do joins a bit differently. They're my main aims at the moment! I'll also add a preprocessor for the compiler to massage it into a nicer form there. I discovered that joins can be done with a pretty sweet syntax in SQL: (tableA LEFT JOIN tableB) RIGHT JOIN tableC This is pretty much perfect for my purposes. Flipping alias maps just makes more sense and removes a whole bunch of `flip-map` calls that would be unnecessary if the aliases were the other way around. The user-facing side of the DSL will be left unchanged, though. The user provides an `{old-name new-name}` map and internally we convert that into `{new-name old-name}`. Like magic. I'm also adding a bunch more tests. Hopefully that will make things more likely to work for long periods of time. Peace out!
2013-05-24Fix a bug in `resolve-fields`Carlo Zancanaro
The recursive calls to `resolve-fields` were not being made due to programmer error. This has been fixed, so now the field resolution stuff should work properly again. This is really highlighting the need for better testing. Get on that!
2013-05-23Simplify the compiler, better subquery supportCarlo Zancanaro
The compiler's been simplified a bit by breaking out the `writer` stuff into its own namespace and by generally making the monadic stuff better. It's all hidden behind a nice, simple, `clojure-sql.compiler/compile` function now. Call that and you'll get back what you need. (Internally it's a writer monad which is really modelled as a state monad with the only operation able to be performed on the state being `tell`.) Subqueries are now handled by the DSL in such a way as to not blow up everything. Subqueries have no support for referencing values in the superquery, though, so their utility is quite limited at present. Thinking about how to do subqueries properly may be difficult.
2013-05-15Split out core into compiler/dsl/query.Carlo Zancanaro
The query namespace really only exists because I didn't want to put it in dsl, but I couldn't put it in core without a circular dependency. Users should only have to :require core to do things, though. It just aliases other stuff to make that work.
2013-05-15Update readme, add stubs, make two vars private.Carlo Zancanaro
2013-05-15Remove two bits of code that were lying around from experimentingCarlo Zancanaro
2013-05-15Fix query printing, operators, make joins better (also implicit on clause)Carlo Zancanaro
Queries now print out their `compile-query` output when they are printed, rather than complaining about `print-method`. This is completely a better idea, so whoo! Operators now compile more nicely, and SQL functions can be used too. So stuff like (substring :name 1 3) will work for getting the first three letters of the :name field. Joins now handle outer stuff more nicely, and compile to "INNER JOIN" rather than just "JOIN" (they're the same in SQL, but this makes the intent more clear). Additionally, joins now automatically add an equality constraint to fields which are aliased the same. So if two relations have shared fields then (join rel1 rel2) will give the natural join of the two relations (an on clause can still be provided, but it will be put in a conjunction with the implicit one). If the implicit on is generated for an OUTER join then the duplicate field which cannot be NULL is the one which will be selected (for INNER joins, or joins without an implicit on, there is no ambiguity).
2013-05-15Change some error reporting stuff. Nothing major.Carlo Zancanaro
2013-05-14Fix precondition on renameCarlo Zancanaro
The precondition was too strong. Loosen it just enough to make the function useful in all the ways it should be without allowing bad cases through.
2013-05-14join and rename preconditions removing ambiguity, `on` now optionalCarlo Zancanaro
`join` and `rename` both had the ability to introduce some ambiguity, whether by renaming two fields to the same alias (which one should use that alias?) or by joining two fields with the same alias (which one should use it?). Some preconditions have been added to warn against some ambiguous use cases (although I have just now realised the rename precondition is insufficient, so a new commit will be coming soon).
2013-05-14Throw a nicer exception on ambiguous field, also some cleanupCarlo Zancanaro
2013-05-14Parametrise deref behaviour, add two small tests.Carlo Zancanaro
Now a user can decide what the query's behaviour on deref should be. This means a user using jdbc can plug in with (set-query-deref-behaviour! #(... jdbc-query-code-here ...)) if they want, but if a user wants to use the code for something else then they can do so without needing to import jdbc stuff. (I'll admit I'm not sure what else they'd do with it, but that's slightly beside the point.) Still left to do is to provide a helper for the common case (performing an SQL query with jdbc).
2013-05-14Apparently I got the jdbc query syntax wrong. Corrected.Carlo Zancanaro
The parameters should be passed in the `rest` of the vector, not as a separate seq. My bad.
2013-05-14Fix ordering issue, split out string parameters for jdbc stuffCarlo Zancanaro
The string parameters are now put in the query as a '?' and the string which should go in their place is now placed in an auxiliary list when the query is constructed. This should make it easier to avoid SQL injection stuff. (Although table/column names are still vulnerable to SQL injection, they should not be dynamic so the issue should be minimal.) There was also another issue where some things were used before they were declared (as a result of repl development) which has now been corrected.