Uwe Grauer wrote: > 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.
Something needs to be done so this isn't as ugly: >> 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. > But i know that there are different implementations which are used in > databases to generate such numbers. Generating is not part of this problem. Right now just interested in how they appear on the screen. Carl K _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
