Commit message (Collapse) | Author | Age | Files | Lines | ||
---|---|---|---|---|---|---|
... | ||||||
* | better column disambiguation | Nick Kallen | 2008-05-05 | 4 | -8/+14 | |
| | ||||||
* | last of the cleanup -- FOR THE MOMENT | Nick Kallen | 2008-05-04 | 5 | -29/+24 | |
| | ||||||
* | missing file | Nick Kallen | 2008-05-04 | 1 | -0/+17 | |
| | ||||||
* | cleanup | Nick Kallen | 2008-05-04 | 4 | -41/+38 | |
| | ||||||
* | reorganization | Nick Kallen | 2008-05-04 | 2 | -81/+79 | |
| | ||||||
* | introducing structural recursion | Nick Kallen | 2008-05-04 | 3 | -25/+5 | |
| | ||||||
* | cleanup | Nick Kallen | 2008-05-04 | 5 | -15/+120 | |
| | ||||||
* | cleanup | Nick Kallen | 2008-05-04 | 1 | -105/+2 | |
| | ||||||
* | cleanup | Nick Kallen | 2008-05-04 | 2 | -8/+4 | |
| | ||||||
* | cleanup | Nick Kallen | 2008-05-04 | 1 | -10/+6 | |
| | ||||||
* | additional testing | Nick Kallen | 2008-05-04 | 1 | -7/+2 | |
| | ||||||
* | minor cleanup | Nick Kallen | 2008-05-04 | 6 | -46/+40 | |
| | ||||||
* | Table names seem to be disambiguated. | Nick Kallen | 2008-05-04 | 10 | -77/+105 | |
| | | | | - Code is a mess, about to undergo some refactoring | |||||
* | finally fixed table aliasing issues | Nick Kallen | 2008-05-01 | 4 | -22/+20 | |
| | | | | - the solution is currently ugly, but i have an idea how to clean it up | |||||
* | naming of aliased relations seemed to be solved; now aggregate relations are ↵ | Nick Kallen | 2008-05-01 | 6 | -22/+32 | |
| | | | | still broken | |||||
* | the big obstacle | Nick Kallen | 2008-04-30 | 4 | -17/+11 | |
| | ||||||
* | automatically aliasing tables | Nick Kallen | 2008-04-28 | 7 | -42/+50 | |
| | ||||||
* | attribute disambiguation | Nick Kallen | 2008-04-27 | 2 | -12/+6 | |
| | ||||||
* | results of a select query are a hash indexed by attribute rather than string | Nick Kallen | 2008-04-27 | 2 | -10/+12 | |
| | ||||||
* | - new todo items | Nick Kallen | 2008-04-19 | 2 | -0/+6 | |
| | | | | | - alias to_sql to to_s - added column_for to join (untested) | |||||
* | in fact, when doing subsequent orderings, we assume that the previous ↵ | Nick Kallen | 2008-04-18 | 1 | -5/+9 | |
| | | | | orderings have taken effect and therefore where the new ordering finds things equal, the previous ordering should take effect | |||||
* | when ordering, the last order wins | Nick Kallen | 2008-04-18 | 1 | -9/+3 | |
| | ||||||
* | officially renamed active_relation to arel | Nick Kallen | 2008-04-18 | 34 | -0/+1090 | |