suever
commented
9 years ago From darcymason@gmail.com on April 05, 2013 05:53:42
I had a quick look at this. The UID includes the time, and the smallest resolution is microseconds. Apparently that is not fast enough. There are a few possible paths:
- base the UID on something else, but a finer time resolution could probably hit the same problem
- update documentation to note the microsecond issue ... if the calling code needs multiple UIDs "at once", then it could get one and add its own suffixes to create the others
- add a counter in the generate_UID code as suggested in the submitted issue. There is already code, though, to optionally truncate if the UID becomes too long, and I'm not sure if that limit might be hit.
- additionally, could add an optional argument to return a specific number of UIDs as a tuple. Then the code could simply increment the microseconds on the first one (not increasing the length)... and store the last one to ensure that subsequent calls started later than that
Anyone have ideas on these or other options?
Status: Accepted
From jog...@gmail.com on April 02, 2013 09:25:43
What steps will reproduce the problem? 1. Call dicom.UID.generate_uid() twice in two subsequent calls What is the expected output? What do you see instead? - I expect that uids are different. What I see, is that the UIDs may actually be identical. What version of the product are you using? - pydicom 0.9.8 _NOTE_: any text or attached files posted with the issue can be viewed by anyone. You are solely responsible to ensure that they contain no confidential information of any kind. Please provide any additional information below. - The dicom.UID.generate_uid() should include some kind of counter that is incremented between successive calls.
Original issue: http://code.google.com/p/pydicom/issues/detail?id=124