I forgot to add the dev channel, so I will do this in post-sent
process in order for interested parties to participate as well.
My earlier question was:
When Wikibase was in its infancy was it ever discussed to use PDO  as
possible abstraction layer for database connection in order to avoid
low level db specific implementations.
Would it make sense (also to counter the discussions about which DB is
supported or not) for SMW to use the PDO objects to do the actual
querying on behalf of the database or does this adds to much overhead?
 http://php.net/manual/en/book.pdo.php interface for accessing
databases in with each database driver (sqite, mysql, postgress etc.)
is implementing and exposing database-specific features
PS: I just had a quick peak but it seems the mw-sqlite connector uses
the PDO as base implementation.
---------- Forwarded message ----------
From: Jeroen De Dauw <jeroendedauw@...>
Date: Fri, 17 May 2013 14:47:07 +0200
Subject: Re: PDO for SMW/Wikibase
To: James HK <jamesin.hongkong.1@...>
To be clear, with PDO you mean the actual
http://php.net/manual/en/book.pdo.php right, and not just something similar
to it? If so, I don't know that much about PDO and have never really used
It however seems like an implementation choice for the store objects.
Having proper stores that abstract away storage access (so no more SQL
outside the stores, not even the notion that relational DBs are used for
one implementation should be visible outside) is one of the things SMW in
not doing to well on. (Though perhaps better then MW core.) If this gets
fixed, then the application as a whole will simply not have to care about
if there is some crappy manually constructed SQL, if there are PDO objects,
if things are written to a flat file, or if things are transmitted via
IPoAC to a data center at the other side of the universe. Since we
currently do not have such proper abstractions, it will not be easy to
completely fix this, and require gradual improvements.
I forgot the name of the pattern to follow here, though I guess you get the
idea. An example of this, which as far as I can tell has not big issues,
can be found in SMW: the PropertyStatisticsStore interface and its
PropertyStatisticsTable implementation. These can also serve as an example
of how to rewrite earlier code as this is replacing badly abstracted
introduces not much earlier.
Be careful to not make the same mistake I made with ORMTable/ORMRow: though
such objects might be convenient for implementing access to some
persistence mechanism, you really ought to not expose them to the rest of
your application, and really ought to not put any business logic into them.
I recommended doing both when I wrote this code and sadly enough followed
my own advice there for the EducationProgram extension, which now has a
pile of hard to solve design problems as a result.
Btw, why is this not on the dev list? ;p
Jeroen De Dauw
Don't panic. Don't be evil.