Having ported an application from PHP to .NET, I strangely assumed (without looking at the code) that porting Subtext to MySQL will be similarly simple. After all, I reasoned, it's just a database port vs a language port that I've done earlier.
I also thought that Subtext is organized along a traditional 3 tier pattern. In fact, Subtext is infinitely more complex. It has a remarkable amount of code for an application, the sole purpose of which is to list articles. But once you think about it, the code must support a ton of features for the engine to be considered usable:
- Spam Prevention
- Article Creation
- Friendly URLs
In addition, Subtext is fairly well married to System.Data.SqlClient. Even assemblies that don't directly make database calls make use of SqlException.Number values, which are non-generic across databases. In fact, the corresponding MySQL exception is not nearly as complete as the Microsoft one.
Between 1.9.5 and 2.0 releases, the team ditched Microsoft Data Application Block in favor of Subsonic (Rails-like environment for .NET). In theory, Subsonic supports MySQL, but the error propagation, upon which Subtext relies upon, is still database provider specific.
Finally, there is the matter of scripts for building tables, views and stored procedures. It's a pretty non-trivial amount of script to convert to MySQL. Tables can more or less easily convert with the help of conversion tools, but sprocs will require some major TLC.
Subtext 2.x is a moving target and seems to be on hold due to life events. Version 1.9.5 is set in stone. So it looks like the fastest way to produce something viable would be to try and marry v1.9.5 to MySQL.
Clearly the first thing to do is to convert all the SQL scripts to MySQL, regardless of what strategy I'll take. I've already started doing that and a bunch of tables (and a sproc or two) have been converted. Unfortunately the process is taking a while because I have a very limited time to do this and very limited knowledge of MySQL.
Second step would be to replace Microsoft Application Block with MySQL equivalent.
Third step would be to abstract way SQL Server specific errors upon which Subtext depends.