kolibri-discuss team mailing list archive

[Anders Steinlein <anders@xxxxxxxxxxxx>]

On Mon, 2008-12-08 at 21:32 +0100, Thorbjørn Hermansen wrote:
> [...]
> 
> I'll look into transaction/lack of support for transaction in some
> MySQL engines when I have time, and also buffered/unbuffered result
> set.

I've had a look at the good progress that has been done here. :-) Your
implementation brings up some more general points regarding both
transactions and result sets.

Regarding the latter, I think we first of all have to determine whether
or not we want to actually support a choice between buffered and
unbuffered results. How common is it really to jump to specific rows in
a result set? In Kolibri's context, all query abstraction methods
(getObjects() and friends) would be using unbuffered results anyway, so
buffered results would only be [potentially] useful for manually
handling the results. What do you usually do outside of Kolibri, and
what do other people think? If we are to support both buffered and
unbuffered results, we should probably make it a general thing for the
database layer and not specific for MySQL.

As for transactions, it seems good to allow autocommit to be turned
on/off pretty much as you've done, given the MyISAM engine. But the
question comes up again if this is something we might want to make
general?

I haven't done a complete review until the above issues are determined,
but a few things I can note right away:
- We use DatabaseException instead of a general Exception for database
  related exceptions (except for SqlException which is even more
  specific).
- free_result() might be called on the result set in query(), but this
  method doesn't seem to exist?
- isset() should be used instead of array_key_exists(), i.e. in the
  connection constructor, as it's twice as fast.
- MySQL doesn't have a boolean type, does it? I didn't last I looked,
  and in that case escapeValue() must be fixed.
- Style issues, but that is unimportant at this stage. :-)

-- 
Regards,
 \Anders