[Erp5-dev] refactoring the uid generation

[Alexandre Boeglin]

Le Mercredi 18 Mai 2005 17:56, Yoshinori Okuji a écrit :
> I have investigated some potential problems in uid generation, and
> solved them mostly. Since this change is significant, be careful
> about making a backup when you update your products.

Hello,

Here is another bug related to this change.

When you copy or delete elements from a ListBox, it always fails with 
the message "Sorry your selection has changed".

So, I uncommented the log messages in SelectionTool, and here's what it 
gives me :

##########################################
2005-05-24T11:05:46 INFO(0) selectionHasChanged, md5_string 
8b411264fc92f0a3cfd207c7ac81fb19
------
2005-05-24T11:05:46 INFO(0) selectionHasChanged, object_uid_list 
[1991716041]
------
2005-05-24T11:05:46 INFO(0) selectionHasChanged, new_md5_string 
3f037fcf9e345fca99015bed3f75ef0d
------
2005-05-24T11:05:46 INFO(0) selectionHasChanged, return... True
##########################################

I wondered why the md5sum changes, as the uid is still correct, so here 
are the tests I made :

##########################################
>>> import md5
>>> list = [1991716041]
>>> md5.new(str(list)).hexdigest()
'3f037fcf9e345fca99015bed3f75ef0d'
>>> list = [1991716041L]
>>> md5.new(str(list)).hexdigest()
'8b411264fc92f0a3cfd207c7ac81fb19'
##########################################

So the problem is that once, the uid is treated as as long, and the 
second time, it is treated as an int.

My first guess on how to fix it is to make functions like getUid always 
return a long value, but it doesn't sound like a seamless change to 
do ...

Any comments ?


Regards,
Alex