The new db-layer in Phorum-5.2 kicks ass

Thanks for maurice’s pulling me into the db-layer I added my “own” mysql-mysnip-layer which handles the queries done.
The change from 5.1 to 5.2 brought up a split db-layer with one file containing all the queries for mysql and calling a function for actually running the query and (optionally)
returning the rows.
And that second part is simply extension specific like for mysql and mysqli extensions. I think it would be simple to add another for pdo but thats a different topic.
For now I added another “extension”-specific part for mysnip which looks into the queries to check if they need rewriting for the partitions used.
The partition-specific tables have some marker in there which tells where the partition number should be and that marker is replaced with the partition-id on querying.
If the partition-id is not yet available in for the current forum-id its retrieved from the database.

That functionality allows me finally to run through all the upgrades as we’ve added a flag to the queries which need to be run for each partition.
We stumbled about it when I was wondering how real-name upgrades are handled now as these have to run through all partitions where that user could have been posting to.
The upgrades from my early version to current 5.2 take a while but overall they are running fine.
Another nice thing is that I don’t have to hack the actual layer which contains the queries and can take that part from the distributed code, only the “extension-specific” code changed and is in a separate file. No more relying on a module to run and rewrite the table-names which would only run once on a page-view.

To cut a long story short: its great and should allow you all kinds of changes to the db-layers without touching the queries. It should even be much easier to write a layer for another database-system (anyone volunteering? ;) ).

No comments yet

Leave a reply