I agree with George here. In some platforms, dealing with large integers is a bit painful.
On Jun 2, 2011, at 11:24 AM, George Reese wrote: > I understand they are large integer fields. But for consideration of > portability, they are strings. > > Sent from my iPhone > > On Jun 2, 2011, at 21:14, Jorge Williams <jorge.willi...@rackspace.com> wrote: > >> >> On Jun 2, 2011, at 12:18 PM, George Reese wrote: >> >>> I hate UUIDs with a passion. >>> >>> * They are text fields, which means slower database indexes >> >> They are not text fields they are large integers and you should store them >> as such. Some databases offer direct support for them. >> >>> * They are completely user-unfriendly. The whole "copy and paste" argument >>> borders on silliness >> >> If you supply links in the rest api -- you fix the problem of users having >> to deal with them for the most part. >> >>> * The bursting scenario makes no sense to me. Why do two different clouds >>> need to agree on uniqueness of resource IDs? (said as one of the few people >>> actually doing bursting) >>> * And uniqueness across regions for "share nothing" can be managed with a >>> variety of alternative options without resorting to the ugliness that is >>> UUIDs >>> >> >> Would love to here your ideas on this. >> >>> On Jun 2, 2011, at 7:40 PM, Glen Campbell wrote: >>> >>>> >>>> There was another specific use case, where someone with a private >>>> OpenStack cloud was bursting into a public cloud. UUIDs would help ensure >>>> the uniqueness of identifiers in that case. >>>> >>>> >>>> >>>> On 5/29/11 8:43 PM, "Mark Nottingham" <m...@mnot.net> wrote: >>>> >>>>> Ah -- makes sense. Thanks. >>>>> >>>>> On 30/05/2011, at 11:40 AM, Ed Leafe wrote: >>>>> >>>>>> On May 29, 2011, at 9:01 PM, Mark Nottingham wrote: >>>>>> >>>>>>> WIth regards to UUIDs -- I'm not sure what the use cases being >>>>>>> discussed are (sorry for coming in late), but in my experience UUIDs >>>>>>> are good fits for cases where you truly need distributed extensibility >>>>>>> without coordination. In other uses, they can be a real burden for >>>>>>> developers, if for no other reason than their extremely unwieldy >>>>>>> syntax. What are the use cases here? >>>>>> >>>>>> >>>>>> The primary use case I can think of is a deployment with several zones >>>>>> that are geographically dispersed. Since each zone is shared-nothing >>>>>> with other zones, UUIDs are the most logical choice for instance IDs >>>>>> that need to be unique across zones. This is precisely the use case that >>>>>> UUIDs were created for. >>>>>> >>>>>> In my experience, UUIDs are no more of a programmatic burden than any >>>>>> other sort of PK; the only place where they are "unwieldy" is when >>>>>> humans have to type them into a command line or a browser URL. But since >>>>>> most humans doing that would have access to copy/paste, it isn't nearly >>>>>> as bad as it might seem. >>>>>> >>>>>> >>>>>> >>>>>> -- Ed Leafe >>>>>> >>>>>> >>>>>> >>>>>> Confidentiality Notice: This e-mail message (including any attached or >>>>>> embedded documents) is intended for the exclusive and confidential use >>>>>> of the >>>>>> individual or entity to which this message is addressed, and unless >>>>>> otherwise >>>>>> expressly indicated, is confidential and privileged information of >>>>>> Rackspace. >>>>>> Any dissemination, distribution or copying of the enclosed material is >>>>>> prohibited. >>>>>> If you receive this transmission in error, please notify us immediately >>>>>> by e-mail >>>>>> at ab...@rackspace.com, and delete the original message. >>>>>> Your cooperation is appreciated. >>>>>> >>>>> >>>>> -- >>>>> Mark Nottingham http://www.mnot.net/ >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~openstack >>>>> Post to : openstack@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~openstack >>>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>>> >>>> Confidentiality Notice: This e-mail message (including any attached or >>>> embedded documents) is intended for the exclusive and confidential use of >>>> the >>>> individual or entity to which this message is addressed, and unless >>>> otherwise >>>> expressly indicated, is confidential and privileged information of >>>> Rackspace. >>>> Any dissemination, distribution or copying of the enclosed material is >>>> prohibited. >>>> If you receive this transmission in error, please notify us immediately by >>>> e-mail >>>> at ab...@rackspace.com, and delete the original message. >>>> Your cooperation is appreciated. >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~openstack >>>> Post to : openstack@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>> >>> -- >>> George Reese - Chief Technology Officer, enStratus >>> e: george.re...@enstratus.com t: @GeorgeReese p: +1.207.956.0217 >>> f: +1.612.338.5041 >>> enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - >>> http://www.enstratus.com >>> To schedule a meeting with me: http://tungle.me/GeorgeReese >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp Mike Mayo 901-299-9306 @greenisus _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
