Hi, 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 [1] 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? [1] 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. Cheers ---------- Forwarded message ---------- From: Jeroen De Dauw <jeroended...@gmail.com> Date: Fri, 17 May 2013 14:47:07 +0200 Subject: Re: PDO for SMW/Wikibase To: James HK <jamesin.hongkon...@gmail.com> Hey, 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. 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 Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
