| Age | Commit message (Expand) | Author |
|---|
| 2013-07-12 | Add a rename helper to turn queries into "subobjects" in the result....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.
| Carlo Zancanaro |
| 2013-07-06 | Make `sort` able to take expressions rather than just table names. | Carlo Zancanaro |
| 2013-07-06 | Bump the version, put Midje back in as dev dependency | Carlo Zancanaro |
| 2013-07-03 | Add fields to union/intersection result queries | Carlo Zancanaro |
| 2013-07-03 | Remove midje dependency and now useless tests (will add tests later) | Carlo Zancanaro |
| 2013-07-03 | Add SCM info to project.clj | Carlo Zancanaro |
| 2013-07-03 | Added tag 0.1.0 release for changeset a04a90ac3937 | Carlo Zancanaro |
| 2013-07-03 | Update the README to include a leiningen dependency vector | Carlo Zancanaro |
| 2013-07-01 | Bump the version number: 0.1.0 | Carlo Zancanaro |
| 2013-07-01 | Change the condition for union compatible (require projections first) | Carlo Zancanaro |
| 2013-07-01 | Make fields compile in a deterministic order (necessary for union stuff) | Carlo Zancanaro |
| 2013-07-01 | A bit more readme changing | Carlo Zancanaro |
| 2013-07-01 | Add union/intersection to the dsl | Carlo Zancanaro |
| 2013-07-01 | Update the readme some more | Carlo Zancanaro |
| 2013-07-01 | Remove some extra code that was left sitting around | Carlo Zancanaro |
| 2013-07-01 | Update the readme | Carlo Zancanaro |
| 2013-07-01 | Move Midje into dev dependencies - no sense pulling it in transitively | Carlo Zancanaro |
| 2013-07-01 | Make sure you never try to take a negative number of things! | Carlo Zancanaro |
| 2013-06-24 | Remove a midje file that's no longer necessary...Also: the fix I mentioned in my last commit message may be a little bit hard to
do, but even without explicitly detecting it it will explode in an obvious way.
| Carlo Zancanaro |
| 2013-06-24 | Make dotted fields result in nested maps when querying...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.
| Carlo Zancanaro |
| 2013-06-23 | Make sort and group create subqueries to be correct | Carlo Zancanaro |
| 2013-06-23 | Make select take a map and compile to equality tests. | Carlo Zancanaro |
| 2013-06-23 | Misc changes. | Carlo Zancanaro |
| 2013-06-23 | Fix the README examples. | Carlo Zancanaro |
| 2013-06-22 | Docstrings, one function call change, README update....In the compiler there was one call to `table-name` which should have been
`field-name`.
| Carlo Zancanaro |
| 2013-06-22 | Update project.clj | Carlo Zancanaro |
| 2013-06-21 | Docstrings, re-export from core better (with metadata) | Carlo Zancanaro |
| 2013-06-21 | Update the README a bit. | Carlo Zancanaro |
| 2013-06-21 | Return records on update, return just a count on delete (jdbc) | Carlo Zancanaro |
| 2013-06-21 | Add take/drop, move jdbc stuff, document default of postgres...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.
| Carlo Zancanaro |
| 2013-06-20 | Clean up, add an assertion. | Carlo Zancanaro |
| 2013-06-20 | Well, that didn't work. Whatever. | Carlo Zancanaro |
| 2013-06-20 | Fix updates, add "use-jdbc!" function to core. | Carlo Zancanaro |
| 2013-06-20 | Make core nicer, pass the "type" of query to executors | Carlo Zancanaro |
| 2013-06-20 | Clean up the query deref, make insert!, update! and delete! work | Carlo Zancanaro |
| 2013-06-20 | Fix a stupid null-pointer exception | Carlo Zancanaro |
| 2013-06-20 | Fix compiling of n-ary operators (0 & 1 args), add operator aliases...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.
| Carlo Zancanaro |
| 2013-06-20 | A few small changes/fixes to join behaviour, and code cleanup...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).
| Carlo Zancanaro |
| 2013-06-17 | Rename sort-by, add grouping, refactor+fix some join stuff...`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.
| Carlo Zancanaro |
| 2013-06-16 | Fix up some more join stuff, and a bit of sorting stuff. | Carlo Zancanaro |
| 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 |
