kolibri-discuss team mailing list archive

[Anders Steinlein <anders@xxxxxxxxxxxx>]

On Sun, 2008-12-07 at 21:09 +0100, Thorbjørn Hermansen wrote:
> Hi all.. two or three people :-)
> 
> I have just written my first few lines of Kolibri's new MySQL database
> connection and result layer and the wish list example is starting to
> fly with MySQL too! :-) I haven't pushed any code yet though (guess
> I'll do that soon), but I got some ideas while implementing the two
> classes:

I added you as assignee on the mysql-support blueprint, welcome! :-) I
haven't looked at much of the code yet, but one of the first things we
should figure out is how this relates to the example app. I'm opposed to
the idea of cloning the application just to make it support MySQL, but I
can see the argument to having it for testing the MySQL driver during
development... As it is now, we use SQLite simply to make it dead simple
to try and experiment with Kolibri without setting up a database. If
it's going to support MySQL, we should also add PostgreSQL support and
somehow integrate it all in the same code base.

>      1. The private isPureNumber method is now defined in all sub
>         classes of DatabaseConnection. Should it be put in the super
>         class itself or maybe a utility lib?

You're right, good catch. Will fix.

>      1. A thought about the prepareQuery method in DatabaseConnection
>         which extracts placeholders in SQL querys from properties in
>         the incoming object: It is now only possible to map
>         ":placeholder" to "$object->placeholder" as far as I can see.
>         Should we try and figure out if the :placeholder could be a
>         possible method in the object too? One example which I can
>         think of when this can be useful is when we are representing a
>         date with PHP's DateTime object. We can't just simply ask for
>         the DateTime property in our object and insert that where the
>         placeholder was as we do with strings and numbers as we have
>         to go through $dateTime->format() to get the date represented
>         as a string which the DB can use (at least as far I know). So,
>         in this case it can be nice to get a return value from a
>         method call on the $object and put that in the placeholder's
>         place.

I took a look at this, and am a bit surprised that DateTime doesn't
implement a __toString() method (though one could argue what it should
output). For objects that provide sane conversion to strings, the simple
"$object->placeholder" scheme would still work. However, I'm unsure
whether this is something that should be supported at query preparation
level as to opposed to, say, an implemented preSave() method. But let's
consider how this would be supported; should a :placeholder look for a,
say, preparePlaceholder() method before or after it looks for a
property?

>         Another solution to this is to check somewhere if
>         $object->placeholder is a DateTime object, and if so do the
>         correct format call and put the return value in the
>         placeholder's place. Kinda like we are escaping strings, we
>         automatically take care and transforms a DateTime object into
>         a string representing it.

If we took this route we would all of a sudden have to consider support
for all sorts of other object types. I think a general solution might be
better, or convince PHP devs to have sane __toString()
implementations. ;-)

-- 
Regards,
 \Anders