As an example, the "postcard" package stores blobs directly in its
table rather than within the content repository.
Why is this a problem? Well ... the differences between Oracle and PG
large-object handling is hard to hide in the simple model we're using
in the query dispatcher. The content repository itself can hide these
differences internally and provides a consistent API to clients which
easily fits into the query dispatcher scheme of customizing SQL.
The content repository also optionally allows the creation of objects
under its control in the host file system rather than the DB. While
not particularly relevant to the "postcard" package, it does make
sense to at allow optional configuration of, say, the photo album
package to store photos directly in the file system for increased
system performance (especially in PG, where BLOBs are base64'd by my
driver hack and therefore require conversion whenever a user downloads
one).
OK - two advantages, one of them - hiding LOB differences behind a
consistent API - major.
The disadvantages? Possible issues in regard to scalability.
Slightly more complicated code in the package using LOBs. Other than
that I can't think of any.
The scalability issue worries me a bit, but the benefit of hiding LOB
differences is significant now that we support both PG and Oracle.
And that significance increases for every RDBMS we add to the list in
the future.
So, what do people think? Is the cost too high to mandate use of the
CR for all modules which store BLOBs?
(BTW the APM's already been converted to store tarballs in the CR,
DanW did it and the changes look quite simple).
