On Apr 22, 2006, at 9:09 PM, Jesus Cea wrote:

>
> David Binger wrote:
>> Here is a thought.  Suppose you defined, very carefully, a
>> subclass of
>> Persistent that, in addition to doing exactly what Persistent
>> does, also
>> overrides attribute access and setting to put the oid into a set
>> on the
>> Connection.    You would also use a careful subclass of Connection
>> that clears this set on every commit() or abort(), and uses it to
>> avoid certain conflict errors.
>
> I just read (again) the Durus license :-) and I could do a fork. But I
> rather prefer an unified codebase };-).

What I described above is not a fork.  It is just
a module with a subclass of Persistent and a subclass
of Connection,  specially tailored to avoid false conflicts.
>

> I think we could change the durus codebase to be able to use the two
> approaches WITHOUT penalizing "pure" read applications.

> Just add an
> optional boolean parameter to "abort" and "commit", requesting
> "ghostifing" the cache, as I already explained in other email. I can
> elaborate the details, if you wish.
> Applications that don't use the parameter (optional, no code change)
> would work as ever, without performance hit.

I think you should just write the subclass of Connection that
does what you want and include it in your software package.
I don't think a parameter whose value would never change
within a given application, is the right pattern to follow.