The ZODB (Zope Object Database) is a wonderful little invention that provides Zope and Plone with a lot of flexibility. Because it is uses a heirarchical format, it is intuitive and easy to move and copy objects around.

However, it seems that the proper functioning of the ZODB depends heavily on all of the objects stored therein being in good health. This means that if you inadvertently install a product that doesn’t cover all of its bases, you could be up the creek without a paddle when it comes time to copy or migrate the site.

I am currently attempting to upgrade our Faculty’s plone web site to use the new SFU look and feel. I set up a development server a couple of months ago to work on the new skin. Now that it is ready, I would like to create a copy of our site on the same Zope instance so that I can install the skin on that instance, then just change the path so that the change can happen instantaneously.

This strategy would work perfectly if we were working directly on the file system. However, I have encountered a basket full of problems in trying to make this copy. It seems easy enough. You click the little box beside the site in the ZMI, press the "Copy" button, then click the "Paste" button. If only it were that simple.

In my first attempt, it churned for about 30 minutes before returning an error that it couldn’t find a transform for the image/pcx type. After some searching, I found an obscure fix for this issue, involving the temporary removal of one of the python source files for the PortalTransforms package.

My next attempt resulted in some errors relating to an old product (CoreBlog) that was no longer installed in the system. Apparently there were still some remnants left in the ZODB. I couldn’t find any actual CoreBlog objects, but the error seemed to indicate that there were some remnants left in the portal catalog.

So I tried updating the portal catalog to see if that would fix anything. After about 30 minutes of thinking it returned an read-write error.

Next I tried to clear and then rebuilt the catalog. This worked. Now I’m back trying to make a copy of the site… It is still thinking….

Getting to the point

So the point of this post was two-fold.

1. To rant about Plone
2. To suggest to those who might be reading this and have a hand in the direction of Zope and Plone, that the ZMI should be insulated from bad products. Imagine if, when copying files from your hard disk to a flash drive, the operating system crashed because one of the files was corrupt. This would make computers nearly impossible. How about an error log to inform me that one of the files couldn’t be copied – but let the rest of the copy go through. Or better yet, let the copy go through unhindered, allowing whatever problems were existent on the original file to be copied through to the copy. I could live with that.

I have a client that I set up on Plone about 9 months ago. It was a substantial amount of work moving them over to Plone, what with having to make a skin and copy all of the pages into Plone pages. It was all towards making my life easier in the long run, because, in theory, the users would be able to add their own news items and events.

For the first few months this was “sort of” working, but somewhere along the line I started having problems with Zope hanging, and hogging the processor and memory. Now it is at the point where this is happening hourly.

I have played with caching, session timeouts, and packing the ZODB, and anything else I can think of, but the site still seems to hang. The error logs are not helpful as they don’t give any indication that I can see as to what is causing the hanging.

So I decide to try to upgrade to the latest version (Plone 3 – I’m running 2.1). So I install a newer version of Python (2.4.4), and a new version of Zope (2.10), and finally I try to import and migrate one of my sites into the new instance. 2 hours of torture later I find that Plone 3 changed the way it handles its workflows and it is completely incompatible with the way that they were handled in Plone 2.5 and lower – so none of my add-on products will work (including the Forum, Ploneboard).

Well, so much for Plone 3. I guess I won’t EVER be upgrading to that one.

So what about Plone 2.5. Okay.. same deal. Installed different version of Zope (2.9.7) as recommended, then tried to import and migrate the site… But again – since Plone 2.5 changes the way it handles user accounts in an incompatible way, I need to uninstall the CAS module that I use for authentication…. Not today..

So I decide that maybe i just need to install the same version.. So I reinstall Zope 2.8.7, and Plone 2.1.4 and move the ZODB over to this new instance… It appears to be working ok for the first few minutes… however.. an hour later, it too is locking up.

So maybe it’s Python. I install Python 2.3.5 again in its own folder, then install Zope 2.8.7 on top of it, then I try to run my site on this instance…. Oh… but some of the extensions that I had compiled into my other Python 3.5 still need to be compiled in… so I compile/install PIL – seems to work ok — but then it comes to MySQL-Python so that I can access a MySQL database from Plone. This I spent 8 hours on, as there were missing libraries and header files.

Finally when I get it installed, this instance just locks up before I can even do anything…

Perhaps I’m not “smart” enough to run Plone.

I have been fed up with Plone before but keep on persisting because of all of the great features it appears to have. However, the single most important feature for me is that the site stays running. I’m at the end of my rope and really don’t know what to do at this point other than restart the server every hour until I manage to port the site back to PHP – a technology that just works!

In PHP the call_user_func function is used to call a function whose name you won’t know until runtime.   In Dataface I need to do this sort of thing quite a bit because the developers are allowed to implement methods in their delegate classes that follow naming conventions. For example, they might define a method called firstname__permissions() that returns the permissions for the firstname field.   Since Dataface is written to be generic, I can’t very well hard code a call to the firstname__permissions() method inside the Dataface core.

This is where I turned to call_user_func so that I can do something like this:

// Suppose the field name we want to check was passed to us in the $fieldname variable.
$delegate =& $this->getDelegate(); // gets the delegate class
$permissions =& call_user_func( array(&$delegate, $fieldname."__permissions"), $this);

call_user_func will accept a function call as either a string function name (e.g. ‘trim’) or as a 2-element array, where the first element is an object, and the second element is a string which is the name of the method to call on that object. So call_user_func(array(&$delegate, $fieldname."__permissions")) is actually calling something like $delegate->firstname__permissions() (if the value of $fieldname was ‘firstname’).

Problem: Objects in PHP 4 are passed by value.

Now suppose our firstname__permissions() is defined like:
function firstname__permissions(&$record){ ... }. Note that the ‘&’ prepended to the $record parameter means that we want to pass the object by reference. This is necessary in PHP since objects are passed by value by default. There are many reasons why we don’t want to pass objects by value. For starters, if we make changes to the object inside our function those changes will be lost because they would have been applied to a copy of the object and not the object itself.

More problems: call_user_func passes everything by value

So you think you’ve solved your problem by defining firstname__permissions(&$record) to take the $record parameter by reference. WRONG! If we call it like:
call_user_func(array(&$delegage, 'firstname__permissions'), $record) the $record parameter will still be passed by value because call_user_func passes everything by value.

Solution: Don’t use call_user_func

One nice feature of PHP that most responsible PHP developers avoid like the plague is variable variables and variable functions. However this is one case where these come in handy. For instance, suppose we have the case above where we are calling call_user_func(array(&$delegate, $fieldname.'__permissions'), $record);. Call it this way will result in $record being passed by value.

However, we can use a variable method name as follows:

$methodname = $fieldname.'__permissions';
$out = $delegate->$methodname($record);

This solution will call our variable function AND pass $record by reference so everyone is happy.

But be responsible. Don’t over-use variable method calls.

A while back I installed a program called SnapZ Pro X – an application for OS X that allows you to do better screenshots than the built-in OS X ones – you can do movies and stuff too.. Worked OK, but the movies didn’t turn out all that well so I decided not to register it.

The problem is that it overrides the OS X screen shot ability so I can’t take screen shots anymore unless I get rid of it – and now the demo is expired and all of my screenshots end up with watermarks on them. So i try first to run the uninstaller that came with it.. But it gives me an error message saying that an error occurred and that I should contact SnapZ Pro support… It seems to me that this is probably intentional and they are just trying to develop leads… very shady…

I have searched my hard drive for anything with SnapZ in the name, and have removed everything that I could find… but this thing is still there.. somewhere… aghhh!

Be warned! Do not use SnapZ Pro X!

Open Office Base Message Forum

http://sheepdogguides.com/fdb/fdb1main.htm

This guy has some nice tutorials on how to use the Open Office Database tool.

I just ran across the latest release of Open Office.org (version 2.2.) which includes the holy grail of database development: Base. This version contains a built-in database that moves into the realm of filemaker for ease of use. It allows power users to develop tables, views, queries, forms, and reports inside of OpenOffice. What’s more, once you have registered the database, you can use it in the other parts of open office (like Writer and Calc). This is the way it ought to be.

It now looks like Open Office is a perfect development environment for DBAs that need to unroll database solutions for clients. It is available on just about every OS under the sun so there are no compatibility issues. All of the databases are stored in the Open Document format – so a database can be shared and copied.

What really interests me, however, is the fact that these great tools can work with existing SQL databases like MySQL with minimal hassle. That, and the fact that the DBs are stored in an open format.

Here’s the idea: Dataface can create .odb files (the database file format for Open Office) on the fly that will allow users to interact with the database application using the quick and easy Open Office interface. For some things, a web interface is just too clunky. I’m not sure how deep this rabbit hole goes, but I intend to explore it to its limits to see just how much Dataface can be integrated with Open Office.