Carl Karsten wrote: > 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 >
Carl, is there a special dabo-datatype for the uuid's? I don't think so. So how should dabo know how to display it? Uwe _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
