However, what that has to do with my email I don't know. The technique I described and the code I shared specifically creates keys that are in sequence avoiding any collisions.
Then I misread your explanation (and I didn't have time to figure out the subtleties of the code). However, your point is worth repeating that "Generally speaking the generation of a hash value for an entity won't always be unique." and so when using hash values you either have to deal with collisions (e.g., chaining) or, as I now understand your solution to be, engineer uniqueness back into the hash by modifying it (in your case taking the hash of the parent and appending the 'position' of the child node).
For the simple case under discussion, I still think UUIDs - for which there is a built-in CF function - are the simplest, safest solution. Less code, less complexity and good enough performance. Caveat Scott's comment about "putting +13" into the key which I didn't understand - if that really means the 35 character UUID (or is it 36?) won't work for Scott then maybe Matt's more complex solution would be just what Scott needs.
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive." -- Margaret Atwood
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
