On Mittwoch, 7. Januar 2009, Dominik Dejmek wrote: > hi, > we are interested in the postgres support for semantic mediawiki. So > that I and some colleagues have a lot of mediawikis with postgreSQL, we > would like to know how much work it is and what things have to be done, > to assist you to give smw postgres-support > So we must decide, if we change all mediawikis to mysql (what we don't > prefer), or we help smw to get support for postgres.
Great that there is finally somebody who is interested in this! I am not knowledgeable in PostgreSQL (yet), but I expect that there will be only a few real issues that need fixing. Luckily, all database calls done in SMW happen in two (not so small) classes: SMWSQLStore2 and its helper SMWSQLStore2QueryEngine. So all we need to check are the SQL statements in the two files * ./includes/storage/SMW_SQLStore2.php and * ./includes/storage/SMW_SQLStore2_Queries.php Most calls in there use standards MediaWiki methods that work with PostgreSQL already. The most problematic features might be: * Database setup and update. The current code checks the existing tables and modifies them if needed. I guess some of this is specific to MySQL. But there could be other workarounds for creating the right tables, e.g. by importing a fixed scheme manually. The required setup can be found in SMW_SQLStore2.php within the function setup() (I think this code should be readable). * Temporary tables. We use temporary tables (tables that exist only during a single DB session) in order to store intermediate results in the DB to avoid having large amounts of data piped through PHP without need. I don't know how/if temporary in-memory tables work in PostgreSQL. These two are the main issues I see. We also use Autoincrement, which might work slightly different in PostgreSQL, but it should be possible to get something similar in any case (MW also uses Autoincrement after all). In general, SMW can work with any storage implementation that implements the basic interface (see SMW_Store.php), so it is not even required that we come up with code that works in both PostgreSQL and MySQL. If it turns out that some parts need to change completely, it would be possible to subclass the existing storage classes and to overwrite all problematic functions. But of course future PostgreSQL support will be better if all code remains in one piece. A first approach could be to try to use SMW with PostgreSQL and fix things from error to error (noting down each problem, so that I can take care of this in the future). How doable this is does of course depend on your familiarity with PHP/PostgreSQL. It might not require that much time if you are used to those. Documenting all encountered issues is the key to allow the SMW team to maintain postgres support beyond this initial fix. Regards Markus > > thanks for the information > dominik > > > --------------------------------------------------------------------------- >--- Check out the new SourceForge.net Marketplace. > It is the best place to buy or sell services for > just about anything Open Source. > http://p.sf.net/sfu/Xq1LFB > _______________________________________________ > Semediawiki-devel mailing list > Semediawiki-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Markus Krötzsch Semantic MediaWiki http://semantic-mediawiki.org http://korrekt.org mar...@semantic-mediawiki.org
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
