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
> > > > >
> > > >
> > >
> >
>

Reply via email to