Age | Commit message (Collapse) | Author |
|
Now it takes a third "projection" argument in which one can perform aggregate
function over the existing fields. The fields of the resulting query are the
union of the grouping fields and the projected fields (with the projected
fields taking precedence).
If you try to project a field without applying some sort of function to it then
you'll get an exception, but at the moment no function calls are actually
validated as aggregate functions (in order to do so we'd need a knowledge of
all the aggregate functions, which isn't possible in general).
|
|
|
|
|
|
Previously the union/intersection operations didn't work when you tried to
select/project/sort/drop/whatever on them. Now they just automatically
introduce a subquery, which means that they can be used in other operations
automatically. (There is a potential for a minor decrease in query speed, but I
think it's worthwhile to maintain the abstraction.)
|
|
|
|
- it looked ridiculous
|
|
|
|
When queries were being created their internal aliases were defaulting to the
same as their external table names. This would normally have been fine, but in
the case of a rename the simplistic implementation of table renames was leading
to the external name being changed too.
The solution: generate a (unique) random internal name for the table. That way
the rename operation will only rename the unique internal name, not the
constant external name (it would also, in theory, reduce the need for renames,
but that optimisation probably isn't really worth doing for expected work
loads).
|
|
|
|
|
|
|
|
|
|
earlier commit).
|
|
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).
|
|
|
|
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
In the compiler there was one call to `table-name` which should have been
`field-name`.
|