Carl Karsten wrote: > First some definitions. I looked over what google and > http://en.wikipedia.org/wiki/GUID had to offer and came up with this: > > guid: Globally unique identifier. A 16-byte identifier. Guids are most > commonly > written in text as a sequence of hexadecimal digits with some dashes. > > uniqueidentifier: ms sql column data type, uses 16 bytes. nice place to > store a > guid. for the rest of this discussion, consider it synonymous with guid. > > In VFP and MsSql tools (EM, Profiler, Query Analyzer) guids are always > treated > like a 36 char string. I am not sure where (server, client, odbc, vfp, etc) > the > translation takes place between 16 bytes and 36 chars. my guess from > observations: it is not the server, > > The reason I bring this up: > > Save Failed: > internal error: None > SQL: update Counters set Counters.nCounter = 5 where > Counters.kCounters_pk='15?'ÒC²ÕñܾS¤¤' > > I think the framework should take care of translating that into it's hex > representation, complete with dashes, per the wikipedia description. > > Now the kicker: python has nice support for human readable versions of things > that are not human readable. > > "The str() function is meant to return representations of values which are > fairly human-readable, while repr() is meant to generate representations > which > can be read by the interpreter (or will force a SyntaxError if there is not > equivalent syntax). For objects which don't have a particular representation > for > human consumption, str() will return the same value as repr()." - > http://docs.python.org/tut/node9.html > > And because it is related: > "The pprint module provides a capability to ``pretty-print'' arbitrary Python > data structures in a form which can be used as input to the interpreter. If > the > formatted structures include objects which are not fundamental Python types, > the > representation may not be loadable." > http://docs.python.org/lib/module-pprint.html > > So, I can see a case for leaving the internal value of a guid as a 16 byte > number, and hook into __str__ and __repr__ for display purposes. > > This may be worth considering in regards to support for images. It would be > nice to display the header info: > > [EMAIL PROTECTED]:~/dabo/trunk/dabo/dabo/icons$ identify daboIcon096.png > daboIcon096.png PNG 128x128 128x128+0+0 PseudoClass 256c 6kb > > Images is pretty far off of the guid subject, but I think worth considering > as > part of the guid display problem. > > So, given all this fluff, what seems to be in line with the dabo way? > > I am sure someone will say "why not use the guid module" and give the the URL > I > couldn't find. > > Carl K >
Don't know how this exactly is related to dabo. But i know that there are different implementations which are used in databases to generate such numbers. So maybe this is of further interest for you: http://en.wikipedia.org/wiki/UUID There is also a link to a python module: http://docs.python.org/lib/module-uuid.html http://zesty.ca/python/uuid.html Uwe _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
