From: Jeremy F. <je...@go...> - 2004-09-13 23:31:57
|
On Mon, 2004-09-13 at 18:01 -0500, Ian Bicking wrote: > I'm still a little confused about what distinct really means. No two > rows can be indistinct if you are including the primary key in the > select. So what does distinct accomplish? If you could select a subset > of the columns, then distinct would be useful. That could be useful, > probably as another method (e.g., MyClass.selectColumns(['firstName', > 'lastName'])); and there distinct would make sense. Well, one example is when joining. I had a join table with a particular pairing appearing multiple times, so when joining with it, I got the corresponding other tables multiple times. Also, I think I've observed MySQL returning a single row multiple times if you use a select statement containing an OR, and the row matches multiple predicates (but I may be mistaken). One deficiency in this patch is that there's no way to apply "distinct" to SQLObject joins (ones done via join columns). The other, as Marcin pointed out, that it doesn't apply to count(), but that seems to require larger structural changes. Also, this patch copies a little too much from the way reverse() works. Reverse is its own opposite, so it makes sense for select().reverse(). reverse() to be a no-op, but distinct() shouldn't toggle like this (updated patch attached). > The index patch looks good and makes sense to me. Great, thanks. We still need to create indexes on SQLObject's automatically created join tables. J |