| Age | Commit message (Expand) | Author |
|---|
| 2013-06-16 | Fix expression processing in the DSL, notably on vectors | Carlo Zancanaro |
| 2013-06-16 | Bring the DSL back up to previous features, fix the compiler...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.
| Carlo Zancanaro |
| 2013-06-13 | Starting a re-write of the DSL, to be followed by the compiler....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!
| Carlo Zancanaro |
| 2013-05-24 | Fix a bug in `resolve-fields`...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!
| Carlo Zancanaro |
| 2013-05-23 | Simplify the compiler, better subquery support...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.
| Carlo Zancanaro |
| 2013-05-15 | Split out core into compiler/dsl/query....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.
| Carlo Zancanaro |
| 2013-05-15 | Update readme, add stubs, make two vars private. | Carlo Zancanaro |
| 2013-05-15 | Remove two bits of code that were lying around from experimenting | Carlo Zancanaro |
| 2013-05-15 | Fix query printing, operators, make joins better (also implicit on clause)...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).
| Carlo Zancanaro |
| 2013-05-15 | Change some error reporting stuff. Nothing major. | Carlo Zancanaro |
| 2013-05-14 | Fix precondition on rename...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.
| Carlo Zancanaro |
| 2013-05-14 | join and rename preconditions removing ambiguity, `on` now optional...`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).
| Carlo Zancanaro |
| 2013-05-14 | Throw a nicer exception on ambiguous field, also some cleanup | Carlo Zancanaro |
| 2013-05-14 | Parametrise deref behaviour, add two small tests....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).
| Carlo Zancanaro |
| 2013-05-14 | Apparently I got the jdbc query syntax wrong. Corrected....The parameters should be passed in the `rest` of the vector, not as a separate
seq. My bad.
| Carlo Zancanaro |
| 2013-05-14 | Fix ordering issue, split out string parameters for jdbc stuff...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.
| Carlo Zancanaro |
| 2013-05-14 | Most of the RA stuff works now....Need to fix up the compilation to return a query ready for value substitution
by the jdbc stuff, or something (rather than embedding parameters in the
query).
Also need to add insert!, update! and delete! functions.
| Carlo Zancanaro |
| 2013-04-27 | Initial commit. | Carlo Zancanaro |
