This is a nice post: https://rclayton.silvrback.com/do-you-really-need-a-uuid-guid
On Jul 25, 2017 12:42 PM, "DeWayne Filppi" <dewa...@cloudify.co> wrote: > True uuids are seductive, because of their simplicity. But they are huge, > overkill, and meaningless. Imho a structured id is superior if it can be > made to work without a global locking scheme. > > - DeWayne > > On Jul 25, 2017 12:11 PM, "Tal Liron" <t...@cloudify.co> wrote: > >> It's not an issue of thread safety -- it could be entirely different >> processes, on different machines, accessing the same db. It can be solved >> via a SQL transaction, but I feel the whole issue can be avoided by using >> UUIDs. >> >> Using the CLI to access specific nodes is not something I see happening a >> lot outside of debugging. And when you do debug, you'll probably be >> copying >> and pasting a node ID from the logs, so shorter names do not add much ease >> of use. >> >> Again, I would be personally happiest if this was configurable (and >> personally think UUIDs should be the reasonable default). >> >> On Tue, Jul 25, 2017 at 2:01 PM, Maxim Orlov <ma...@cloudify.co> wrote: >> >> > Technically we have no issue with implementing this via uuid or a >> > threadsafe solution for the current index implementation. >> > >> > Getting node data via the cli feels more intuitive using the index based >> > ID, rather than the uuid based ID in my opionion. >> > >> > On Jul 25, 2017 9:49 PM, "Tal Liron" <t...@cloudify.co> wrote: >> > >> > Our code for determining the next index is not concurrently safe (no >> atomic >> > transaction) so I can see it breaking in concurrent use cases (running >> two >> > ARIA commands at the same time). >> > >> > What is to gain here in terms of human readability? In my opinion it >> adds >> > confusion because it gives a false sense of predictability. >> > >> > In my opinion the best compromise is to use base57-encoded UUIDs. These >> are >> > true UUIDs, but use a mix of upper and lowercase alphanumerics ensuring >> no >> > visually ambiguous characters. We have the code for this in >> utils/uuid.py. >> > >> > See also: https://github.com/wyattisimo/base57-ruby >> > >> > On Tue, Jul 25, 2017 at 1:28 PM, Maxim Orlov <ma...@cloudify.co> wrote: >> > >> > > Actually the refactoring was made so the id would be more user >> readable. >> > > The index is determined according to the used indices (it's not just a >> > > running number). If indeed this poses an issue (or if indeed a uuid is >> > > easier to recognize, or even use in a query), let's discuss it >> further... >> > > >> > > On Tue, Jul 25, 2017 at 7:35 PM, Tal Liron <t...@cloudify.co> wrote: >> > > >> > > > We used to use UUIDs but at some point this was refactored. I tend >> to >> > > agree >> > > > with you. >> > > > >> > > > Actually, I would prefer it to be configurable. We have code in >> place >> > for >> > > > ID generation of various types: UUIDs, short UUIDs, and sequentials. >> > All >> > > of >> > > > them would seem useful to me for various scenarios. >> > > > >> > > > On Tue, Jul 25, 2017 at 3:42 AM, Vaishnavi K.R < >> > > vaishnavi....@ericsson.com >> > > > > >> > > > wrote: >> > > > >> > > > > Hi, >> > > > > >> > > > > >> > > > > With my understanding in current ARIA, the node instances are made >> > > unique >> > > > > by prefixing the node name with the 'id of the service' (i.e. the >> > > primary >> > > > > key of the service table) as the instances are specific to the >> > service. >> > > > > >> > > > > >> > > > > What will be the name of the node instances if the default >> instances >> > > for >> > > > > the node template is '3' and how this will hold good during scale >> in >> > > and >> > > > > out? >> > > > > >> > > > > >> > > > > Could UUID be of great help in handling such cases by including >> that >> > > as a >> > > > > column in the database tables of the service and the node? >> > > > > >> > > > > This will wipe out the naming confusions and querying can be made >> > easy >> > > > > with the UUIDs. >> > > > > >> > > > > >> > > > > Looking forward to your suggestion. >> > > > > >> > > > > >> > > > > Thanks, >> > > > > >> > > > > /Vaish >> > > > > >> > > > >> > > >> > >> >
