Updated: Proposal for Abstraction Layer for Modifications in

[Maxwell Kanat-Alexander]

>     Just a note from my experience working on a time reporting feature
> these last week. Getting data in order to process it efficiently may
> preclude use of the Bug object in certain cases; this is admittedly a
> performance hack, but it's the sort of hack that allows reports to be
> generated in anything less than geological time.

	Hey Kiko. Yeah, I've run into this in other scripting languages than
perl, too. Objects can be a big pain.

	I think what might help is Bug::read_fields($ids,$fieldnames) -- A
simple abstraction that would be a static library function, and wouldn't
instantiate any objects. It would just return the fields as an
associative array from the bug id (or ids) that you requested.

	Also, it would probably help centralize a lot of SQL. :-)

	Granted, you don't get to do GROUP BY, ORDER BY, and aggregate
functions, but it would still help in some situations, I'll bet.

	If I was designing a system from the ground-up, I'd probably make
custom API functions for the various GROUP BY and ORDER BY things that
needed to be done commonly, unless I couldn't come up with a way to keep
it all manageable. (I'd really have to draw out a UML diagram to know
for sure.)

	I think that several small SQL queries inside of one transaction (the
result of such abstractions) wouldn't hurt performance. We basically do
that now, in various places (except it's usually several large queries).

	-Max