Forum OpenACS Development: revival of the blobs

Request notifications

Posted by Gustaf Neumann on
Dear all,

Since the early days, the OpenACS content repository supports blobs. Content items of storage type "lob" were used e.g. for user-portraits (and on a few other occasions). Since about 2006 new user-portraits are stored with the storage type "file" due to problems with the lob interface.

As we are running a large instance with a few thousand portraits stored in "lobs", i looked into the problem and fixed the issues visible to me. It looks to me as if the lob interface in the pg driver (nsdbpg) was just implemented for tcl 8.4, there were problems with storing the binary content, streaming the content, or returning the content, since a plain string based interface was used. Furthermore, PostgreSQL requires data of type "bytea" to be decoded with PQunescapeBytea(), which was as well missing in the driver. With these changes it is as well possible to get the lob data out of the system, or to convert it into items of storage type "file".

In case you have old portraits stored on, these should show up no again (on the toolbar and on your /pvt/home page). If you want to use the fixed code in your installation, use the newest version of the oacs-5-9 channel, and wait for the release of NaviServer 4.99.9, which should be released soon.

2: Re: revival of the blobs (response to 1)
Posted by Gustaf Neumann on
I should add that i would not recommend writing new applications with blobs in the OpenACS content repository. In most quality dimensions the storage type "file" is better suited. The mentioned changes help admins to make old data again available to users, and to convert data.

I wonder if we should keep the lob interface for the content repository, or to write a conversion script to turn lob-entries into file-entries and drop the interface afterwards. However, i am not sure about the state/necessity of lobs in oracle.

3: Re: revival of the blobs (response to 2)
Posted by Antonio Pisano on
Lobs have pros and cons, but in my humble personal experience, they are more a pain than a joy.

My 2 cents would be to progressively drop lobs support in content repository, as this would also be more portable between the two DBMSs (and easier to maintain in general).