ChiliProject is not maintained anymore.
Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and
we urge all existing users to migrate their data to a maintained
system, e.g. Redmine. We will
provide a migration script later. In the meantime, you can use the
instructions by
Christian Daehn.
Forums » Develop »
[Proposal] Query Refactoring
Added by Chris Woerle at 2011-09-26 10:47 am
Refactoring of Queries¶
General Opinion¶
- Queries are really powerful and can become even more powerful
- They are generally a performance problem, if they get too powerful
- They should be usable for other things, than just Issues (everything)
- The main logic is well thought
- The implementation has some hard issues (like the problem you cannot query fields starting with o and c via api and such)
- It's in general overkill, to create a sophisticated sql builder like that and I am happy to have it :)
- We should use arel
*
*
Our refactoring.¶
At first we splitted the Query#statement method into it's parts.
This caused problems with pasing all the parameters all the time immediatelly, so say, it wasn't too easy but is done.
The next step would be for example
- create a class called query builder
- move all the building logic there
- create snippets as atomary as possible
- then use arel (this is the most important point to discuss, DO WE WANNA USE AREL?)
- make it easier for other parts of the application to register new query parameters and such.
- TODO: Add list of parts of our statement method (suung)*
Quick comment: using ARel would be nice, but won't be possible until the switch to rails 3, so with luck some time next summer :-/
I don't like the curent way to do queries either, especially because they're limited to issues, duplicate functionality with the search function, shouldn't be split from the issues if they are issues-only, and so on. Regarding your proposal, I think it would be easier to present your ideas with some code examples and/or some diagrams (UML?) to show where you'd like to take this. I'd also enjoin you to attend the next dev meeting so we can discuss this with everyone.
as far as i understand, we can use Arel in Rails 2. In Crabgrass (same situation as in chili, because Redmine was the inspiration for the plugin technologies, the query builder and much more), this has been done. see also http://rails3.community-tracker.com/permalinks/16/using-arel-with-a-rails-2-app
That's why I say 'Arel', not 'Rails 3 Scopes', because it looks different (and is more powerful, the Rails 3 Scopes are still pretty... castrating sql :
Chili/Redmine currently uses SQL techniques, that are not possible with arel, that's, what i am worrying about.
Metawhere and Sequel are two gems, that might help here.
But i would like to discuss that in detail, if the general go for arel is something, we would agree.