On 16 August 2010 17:29, Pedro Ferreira wrote:
>
>
>> Consider using one
>> of these alternatives instead:
>>
>> * Set the IOTreeSet as an attribute directly on the persistent object.
>>
>
> You mean on the persistent object I am using as key?
Yes.
>> * Use http://pypi.python.org/pypi/zope.intid
> libraries that I'm currently including: location, component, security...
>
"libraries that I'm currently *NOT* including" of course :)
--
José Pedro Ferreira
Indico Team
IT-UDS-AVC
513-R-0042
CERN, Geneva, Switzerland
___
For more informatio
> Consider using one
> of these alternatives instead:
>
> * Set the IOTreeSet as an attribute directly on the persistent object.
>
You mean on the persistent object I am using as key?
> * Use http://pypi.python.org/pypi/zope.intid and use the intid for the
> key. (This uses http://pypi.pyth
On 16 August 2010 13:13, Tres Seaver wrote:
> Hanno Schlichting wrote:
>> On Mon, Aug 16, 2010 at 12:14 PM, Pedro Ferreira
>> wrote:
>>> Could this be some problem with using persistent objects as keys in a BTree?
>>> Some comparison problem?
>>
>> I'm not entirely sure about this, but I think us
On Mon, Aug 16, 2010 at 2:04 PM, Pedro Ferreira
wrote:
> I think implementing a stable hash function for your type could make
> this work though.
>
> From what I read, ZODB doesn't use hash functions, relying on __cmp__
> instead. So, I guess I should make my class non-persistent and implement a
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hanno Schlichting wrote:
> On Mon, Aug 16, 2010 at 12:14 PM, Pedro Ferreira
> wrote:
>> Could this be some problem with using persistent objects as keys in a BTree?
>> Some comparison problem?
>
> I'm not entirely sure about this, but I think using p
PyObject_Compare to compare different keys. Persistent doesn't
implement any special compare function and falls back to the standard
hash algorithm for an object. This happens to be its memory address.
The memory address obviously changes over time and the same address
gets reused for different
On Mon, Aug 16, 2010 at 12:14 PM, Pedro Ferreira
wrote:
> Could this be some problem with using persistent objects as keys in a BTree?
> Some comparison problem?
I'm not entirely sure about this, but I think using persistent objects
as keys isn't supported. Looking at the code, I doubt using anyt
