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