Forum OpenACS Q&A: Consequences of changing sec_session_properties.property_value to clob/blob

Collapse
1: Consequences of changing sec_session_properties.property_value to clob/blob
Posted by C. R. Oldham on 10/31/01 09:56 PM
Bug #1222 in the SDM notes that sometimes the package manager tries
to stuff too large a value into the
sec_session_properties.property_value field.  What would be the
danger of converting this field to a blob or a clob (in Oracle--sorry
I don't know the corresponding field in PG)?

It looks like there are only a few places this is accessed
(ad_get_client_property/ad_set_client_property/etc.)

I'm still not clear on how the .xql files work, and recall that some
magic must be done when using bind variables to insert blob/clob
values into Oracle...

Collapse
2: Response to Consequences of changing sec_session_properties.property_value to clob/blob (response to 1)
Posted by Don Baccus on 10/31/01 10:22 PM
The corresponding field in PG is "text", which is in practice as large as  you would ever want it to be.

I've been wanting to visit this issue myself.  clob storage isn't the most efficient thing in the world ... we could pull the old trick of putting strings <= 4000K in length into the existing varchar and longer strings into a clob.  This would fix the APM problem (where you can't install all packages at once).  I don't know of any other place where this has been a problem, the table's really defined to be used for passing around small chunks of stuff.

Collapse
3: Response to Consequences of changing sec_session_properties.property_value to clob/blob (response to 1)
Posted by C. R. Oldham on 10/31/01 10:25 PM
I can take a whack at this if someone can point me to an example of what the .xql file is supposed to look like when you are using clobs.
Collapse
4: Response to Consequences of changing sec_session_properties.property_value to clob/blob (response to 1)
Posted by Stephen . on 11/01/01 09:20 AM
Clobs are inefficient? By default, clobs of length < 4000 chars are stored in-line with the rest of the table data anyway, a pointer to out of line storage is used when size increases (which is a feature). No need for the dual varchar/clob solution.