OQ <overlordq(a)gmail.com> wrote:
> I tried poking at this a bit and got as far as trying to figure out
> what UserArrayFromResult actually needed to create the objects. I had
> pictured going the cheap route and making it a two step operation,
> getting the list of contributors and then pulling in the relevant user
> data based on the obtained list.
I think the bare minimum is nothing at all, if you check out loadFromRow
inside of User.php! The resulting User object would be less than useful,
of course. Seems to me the list of "public" attributes from User is
really only user_id and user_name.
Tim Starling <tstarling(a)wikimedia.org> wrote:
> On 28/04/11 00:15, Greg Sabino Mullane wrote:
> > 1) Manually add in all the columns from the user table to the
> > GROUP BY. Painful, and subject to immediate breakage when a
> > column is added or removed from the user table.
>
> You could add a static function to User which provides the field name
> array. If it were used in User::loadFromDatabase(), then it would be
> immune to bit rot.
Yes, that's a good point: we don't really care about the user table
per se, merely MW's canonical representation of it in User.php.
An interesting approach.
> Can you add a note about this to docs/database.txt and
> docs/databases/postgres.txt? Something explaining why we can't use *
> with group by.
Done.
--
Greg Sabino Mullane greg(a)endpoint.com
End Point Corporation
PGP Key: 0x14964AC8