Using .aggregate_rows() with .get() doesn't work correctly
`aggregate_rows()` was not really intended, when I wrote it, for fetching single instances via `.get()`. Can you explain your specific use case? I might be able to suggest some equally viable alternatives.
 We have an alternative, we just don't use .get(), we just run the normal "list" query, check to see if there are any results, and pick off the first result, it's just not as elegant as using .get() and catching the peewee.DoesNotExist exception

Using an example from the docs: http://peewee.readthedocs.org/en/latest/peewee/quickstart.html

``` python
>>> subquery = Pet.select(fn.COUNT(Pet.id)).where(Pet.owner == Person.id).
>>> person = (Person
...          .select(Person, Pet, subquery.alias('pet_count'))
...          .join(Pet, JOIN_LEFT_OUTER)
...          .order_by(Person.name)
...          .where(Person.id == 1)
...          .aggregate_rows()
...          .get())

...     print person.name, person.pet_count, 'pets'
...     for pet in person.pets:
...         print '    ', pet.name, pet.animal_type
```
 So the `.get()` helper works efficiently by calling `LIMIT 1`. `aggregate_rows()` does not work well with `LIMIT` because the data is de-duped and aggregated (hence aggregate_rows) on the python side. Also note the row**s** -- it is intended to work with multiple rows of data.

You can still achieve what you're going for in O(1) queries, you'll just need to make 2 instead of 1:

``` python
person = Person.get(Person.id == 1)
pets = Pet.select().where(Pet.owner == person)
# or
pets = person.pets
```

In addition to being roughly equivalent in terms of performance, this is probably quite a bit more efficient than `aggregate_rows()`.

Note: I edited your comment to fix the syntax highlighting.
 Do you have any additional questions or thoughts? If not, I will go ahead and close the issue.
 Definitely understand, that's fine on closing it.

It does seem like .get() could just be intelligent enough that if .aggregate_rows() is set on the query that it drops the LIMIT 1, that way aggregate rows still collects the records under the single record but the case where they don't use aggregate_rows() is still optimal.
 Yeah, it would be possible, but I'm loth to introduce special-cases. Particularly because, in my mind, the use-cases for `.get()` and `.aggregate_rows()` are quite different. With `.get()` you have some piece of information to uniquely identify a row, so you're already looking at O(1). Whereas with `.aggregate_rows()` you're looking to grab multiple rows and avoiding the dreaded N+1 query problem. Since `.get()` already implies you don't have N+1, I think it's acceptable to avoid special-casing.

That said, I will update the docs to make this clear. Thanks for reporting the issue!

It only returns one item on the back reference lists even if the item had more in the tables that were joined in.
