[ZODB-Dev] ZODB _v_ attributes are tricky

[Kapil Thangavelu]

On Apr 5, 2004, at 2:00 AM, Dieter Maurer wrote:

> Kapil Thangavelu wrote at 2004-4-4 20:43 -0400:
>> ...
>>>   3. attributes that are garanteed to disappear at the next
>>>      transaction boundary (do we need to control which
>>>      type of transaction boundary?)
>>>
>>>      do we need this type? for what use case?
>>>
>>>
>>>   4. attributes that live precisely for the current request
>>>
>>>      used for things like "_v_skininfo".
>>
>> i think 3 and 4 are similiar enough that they can be merged into one, 
>> ie
>> a transactional attribute, some computation, as zodb is not request
>> bound, ie has no notion of such, it would be better imo to tie it in 
>> at
>> the transaction level.
>
> But, it would make usage such as "_v_skininfo" unrealiable.
>
>   "_v_skininfo" (as it is implemented today) requires that the 
> information
>   remains during the complete request. If an application
>   calls "get_transaction().commit|abort()" during request
>   processing, this usage were no longer safe.

>   This happens regulary when an exception occurs before
>   error handling. "_v_skininfo" might not be defined
>   for error handling (and the wrong "standard_error_message" might
>   be found).
>
>

good point, i'm of two minds, one is that this sort of usage is 
reflective of a broken implementation and that _v_skininfo should be 
stored on the request since that is its scope, perhaps using the 
request _held for storage as well as cleanup facility. two, is that the 
ResourceAttribute would instead of being an attribute with uncertain 
lifetime and txn boundary lifecycle, be one that is also non persisted 
but is not subject to persistent object lifecycle (dirty, ghost, etc) 
but is instead completely application managed. either would requiring 
changing the implementation of _v_skininfo

-kapil