We recently upgraded to PHP4 and now get the message, "Function not yet implemented" - but only on our DBM back-ended wiki's. The mySQL wiki's are fine. Will we have to upgrade all our wiki's to mySQL or is there a workaround? (Or did we simply screw up?) Thanks! SiteMouse
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, the features in 1.2 across the different data stores are not the same. Technically it's not even possible to delete a page from a DBM file; at best you could somehow "delist" it.
DBM files never reclaim used storage. When you read/write a key/value from the DBM, if you write something larger than you read out, it will allocate new space for the value and the old storage location is permanently lost.
There is a Perl script included with PhpWiki 1.2, admin/shrinkdbm.pl, which will copy an old DBM file and make a new DBM file with the same key/value pairs (pages). I've seem savings of several megabytes this way.
PhpWiki 1.2 included a hack to work around this problem with DBM files by padding out the value with spaces when writing and subtacting them when reading. There still is occasional loss of memory but it's almost negligible.
Without a doubt most support requests we get are for MySQL, so you wouldn't be alone in upgrading!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We recently upgraded to PHP4 and now get the message, "Function not yet implemented" - but only on our DBM back-ended wiki's. The mySQL wiki's are fine. Will we have to upgrade all our wiki's to mySQL or is there a workaround? (Or did we simply screw up?) Thanks! SiteMouse
Clarification: Function not yet implemented - only appears when REMOVING pages. Everything else works fine.
Yes, the features in 1.2 across the different data stores are not the same. Technically it's not even possible to delete a page from a DBM file; at best you could somehow "delist" it.
DBM files never reclaim used storage. When you read/write a key/value from the DBM, if you write something larger than you read out, it will allocate new space for the value and the old storage location is permanently lost.
There is a Perl script included with PhpWiki 1.2, admin/shrinkdbm.pl, which will copy an old DBM file and make a new DBM file with the same key/value pairs (pages). I've seem savings of several megabytes this way.
PhpWiki 1.2 included a hack to work around this problem with DBM files by padding out the value with spaces when writing and subtacting them when reading. There still is occasional loss of memory but it's almost negligible.
Without a doubt most support requests we get are for MySQL, so you wouldn't be alone in upgrading!
Dangit, where's my head today? We're using PHPWiki 1.2.