Re: [CFCDev] Structs in a CFC not Quick enough?? (possible bug?)

[Matt Liotta]

I do think using a UUID is one of the easiest ways of getting a unique 
identifier. However, I thought there was more to a taxonomy solution 
than just uniquely identifying a taxonomy node as you also need to 
identify the node's position in the tree. A UUID scheme would require a 
UUID for the node as well as a UUID for the parent which is quite a bit 
of data. Further, actually walking the tree is quite expensive. My 
solution, which I admit was aimed squarely at solving the whole 
taxonomy problem as opposed to just the unique identifier issue solves 
many of the additional problems with trees since the key itself reveals 
hierarchical information. For example, displaying the entire tree's 
contents is a simple iterative loop over the keys in alphabetical 
order. See my original email for more examples of the solutions 
elegance.

BTW, a UUID according to the IETF is an identifier that is unique 
across both space and time, with respect to the space of all UUIDs. 
They specify that a UUID is 128 bits, but they do not specify the 
string representation of those bits. However, Microsoft's original UUID 
implementation, which they submitted to the IETF and it became the 
specification represents a UUID using a 36 character string. Further, 
most of the industry represents UUIDs this way as well. Of course, the 
UUID string that CF generates is 35 characters in length, so it doesn't 
follow the norm; it is different by a hyphen specifically.

-Matt

On Tuesday, June 17, 2003, at 10:22 AM, Sean A Corfield wrote:

On Tuesday, Jun 17, 2003, at 00:09 US/Pacific, Matt Liotta wrote:
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).
----------------------------------------------------------
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).