Hi Marcel, thanks a lot. I have made an SVN update based on your code, though I changed the overall structure a little: the setupX functions are now in a separate class SMWSQLHelpers since they are very generic anyway. In this file, I also keep the definitions of standard datatypes (what to use for page ids, what for titles, what for blobs, etc.) so this is where one can conveniently change those if there are new insights.
It would be helpful if you could check whether the SVN version still works on
your site -- I must admit that I did not set up a testing MW postgres
installation yet. I had to do some fixes and minor changes to get MySQL
working again. I do not expect this to break Postgres, but of course I may
have added new errors, too.
Regarding the types used in Postgres, I suggest that you have a look at the
MediaWiki tables in your Postgres database -- most types SMW uses should agree
with the types of certain MediaWiki columns. I have added comments for
documenting where each type comes from in the new file SMW_SQLHelpers.php.
This is also where you find most of the relevant code now.
If all seems to be reasonably well from your point of view, then I will
release this update with the next SMW release 1.4.2 real soon (it is delayed
already, but I wanted the Postgres part to be added).
I was surprised to see that TEMPORARY TABLEs did not cause any problems for
you. I recall that someone once mentioned this as a potential compatibility
issue. I would still go for release in any case since the temporary table
parts are not strictly necessary (one can switch off the related features),
but maybe you want to check if this is really working. To do this, simply
create three properties where P1 has [[subproperty of::P2]] and P2 has
[[subproperty of::P3]]; then assign some page a value for P1; then do a query
{{#ask: [[P3::+]] }} -- it should show the P1-annotated page (and no error).
Regards,
Markus
On Dienstag, 3. Februar 2009, Marcel Gsteiger wrote:
> Hi all,
>
> I've adapted SMW_SQLStore2 to make it work with PostgreSQL 8.3 backend -
> the database setup/initialization for SMW now runs through without
> problems. Indexes/keys are created/modified as expected; however, I just
> tested the case where a new installation has to be performed. So please
> consider this as experimental "works for me" code.
>
> There are the following differences/problems in my installation compared
> with the original MySQL-Only setup:
>
> 1) DROP TABLE IF EXISTS has been replaced by DROP TABLE, this means that
> removing everything will presumably fail in some cases 2) the data types
> are somewhat different, I don't know if my choices make sense with all
> respects (e.g. substituting "bytea" for MEDIUMBLOB) 3) reordering fields
> cannot be done easily in PostgreSQL - additional fields are always appended
> to the end. If somebody really cares about this, the workaround usually is:
>
> a) do two separate dumps for schema and data; the data dump should be a
> "full inserts" dump for data [including column names] b) modify the schema
> dump accordingly, changing field order as desired c) restore the new schema
> d) restore the data with triggers disabled
>
> 4) For creating/modifying the schema and indexes I used the postgresql
> dictionary (as opposed to the ANSI dictionary that would be a better choice
> for portability). I had to to this becaulse INDEXes do not exist in
> standard ANSI SQL (for good reason; normally indexes are just an internal
> optimization of the database done when the application relies on keys, but
> it seems that most MySQL users don't even know what a key is ;) ).
> Consequently my procedure is dependent on PostgreSQL version 8.3 and
> certainly needs adaptation for releases before 8.3 and perhaps even for
> future releases. Maybe that 8.1 and 8.2 work, but this requires further
> testing.
>
> 5) For security reasons, my setup uses a separate SCHEMA for the
> mediawiki/SMW within the general database (as opposed to using the default
> "public" schema), but this does not seem to make any problems. To make that
> work, I use a login name that corresponds to the schema name and have set
> the search path within postgresql.conf accordingly.
>
> Please find enclosed the diffs against version 1.4.1.
>
> This is my second post for this subject, meanwhile I added a few additional
> corrections and stored the attachment as .txt file so it does (hopefully)
> not get blocked.
>
> Regards
> --Marcel
--
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.
------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
