Mailing List Archive

MySQL support
I am interested in adding MySQL, and possibly MSSQL, support to
DAViCal. I did some poking around the AWL and DAViCal source code and
decided it shouldn't be too difficult. Correct me if I am wrong, but it
looks like the relevant database-specific code is primarily in
AwlDatabase.php and AwlDBDialect.php, and maybe PgQuery.php. The SQL
strings scattered throughout the DAViCal source code can be replaced
with function calls that return strings in the appropriate SQL dialect.

I think a generic approach is best, so that any database server and SQL
dialect can be added. It looks like there was already a good start on
the necessary abstractions.

Am I missing anything?

Jeff Kintscher
websurfer at surf2c.net
MySQL support [ In reply to ]
On Wed, 2010-08-18 at 01:16 -0700, Jeff Kintscher wrote:
> I am interested in adding MySQL, and possibly MSSQL, support to
> DAViCal. I did some poking around the AWL and DAViCal source code and
> decided it shouldn't be too difficult. Correct me if I am wrong, but it
> looks like the relevant database-specific code is primarily in
> AwlDatabase.php and AwlDBDialect.php, and maybe PgQuery.php. The SQL
> strings scattered throughout the DAViCal source code can be replaced
> with function calls that return strings in the appropriate SQL dialect.

The AwlQuery (AwlDatabase, AwlDBDialect) libraries are replacing the
PgQuery one, which was my original library developed circa 2001, or so.
They're the ones that use PDO.

So in the first instance, converting the AWL code to use AwlQuery rather
than PgQuery, and then writing support for a new DB dialect such as
SQLite or Drizzle, or whatever.

My intention is that the dialect libraries should manipulate the SQL
strings internally, in order to make it work in their own dialect,
including presumably writing chunks of stuff in PHP to handle the more
complex stuff that (e.g.) MySQL can't do so well.


> I think a generic approach is best, so that any database server and SQL
> dialect can be added. It looks like there was already a good start on
> the necessary abstractions.
>
> Am I missing anything?

Maybe :-)

In putting the AwlQuery classes together I've tried to layer it such
that there is an opportunity for other databases to be used, but I
*strongly* object to using lowest-common-denominator SQL just so people
can use lower quality databases.

The AwlQuery classes are insufficiently reviewed, for my taste. I wrote
them, but I don't think they've been looked over by anyone sufficiently
critical to make me justify my decisions.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You will triumph over your enemy.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-dev/attachments/20100818/ee06fd33/attachment.pgp>
MySQL support [ In reply to ]
On 8/18/2010 1:56 AM, Andrew McMillan wrote:
>
> My intention is that the dialect libraries should manipulate the SQL
> strings internally, in order to make it work in their own dialect,
> including presumably writing chunks of stuff in PHP to handle the more
> complex stuff that (e.g.) MySQL can't do so well.
>
>
>> I think a generic approach is best, so that any database server and SQL
>> dialect can be added. It looks like there was already a good start on
>> the necessary abstractions.
>>
>> Am I missing anything?
> Maybe :-)
>
> In putting the AwlQuery classes together I've tried to layer it such
> that there is an opportunity for other databases to be used, but I
> *strongly* object to using lowest-common-denominator SQL just so people
> can use lower quality databases.
>
>
By "generic approach," I meant abstracting everything in the
higher-level code and hiding the SQL dialect details in utility
classes. The higher-level code shouldn't care which RDBMS is being
used. Using switch statements in the utility classes to differentiate
between SQL dialects and database access methods is an approach I have
used many times for applications that had to support both MySQL and MSSQL.

//Jeff