New queues can't be created with the deleted queue names

[Trinankur]

Hi,

Not sure if this is a feature or an issue. I am not clear as to why once a queue having a certain queue name is deleted, a new queue with the same name can't be created again.

[daltonfury42]

Hi @Trinankur This was a intentional design constraint we took.

Queue names are used in queue url, hence should be unique. We enforce it as a DB constraint. When the queue is deleted, we only do soft deletes, as we might still need to let our clients have a log of people who had been in the queue.

[Trinankur]

Understood, although this is a very good implementation but what if we could generate the url by hashing the queue name and queue id. That would take away the url constraint and only let the signed up users to have unique Queue name to let them investigate the queue if needed later. Because some users might abuse the system and use up all the good queue names that a client might have used. Not able to create a queue with a queue name of their choice might put some clients off.

[daltonfury42]

That's a great idea, simplicity was the reason we kept the current scheme.

Let's discuss and develop your idea further.

1. The way in which I have seen some of our recurring users use the product is, everyday they creates a new queue for a set of people. For example, today he might be opening his service for the HR department, tomorrow for Marketing. The queue names he creates in the current flow is as follows:

ABC-HR-Nov01
ABC-Marketing-Nov03
ABC-Technology-Nov05
ABC-Marketing-Mov08
...

The unique queue name constraint is forcing the user to naturally create distinct queue names by using dates. Thsi is indirectly helping him indirectly distinguish between past queues.

In your proposed new scheme, one way around this might be to have a uniqueness constraint on (queueName, ownerId).

2. Taking the same case, I find it a little friendlier to be human readable in queue join URLs:

simplq.me/j/ABC-HR-Nov01
simplq.me/j/ABC-Marketing-Nov03
simplq.me/j/ABC-Technology-Nov05
simplq.me/j/ABC-Marketing-Mov08
...

One thing that quickly comes to my mind is to have a auto-incrementing number for each owner as the owner id and then use it in the queue url:

simplq.me/j/83/ABC-HR-Nov01
simplq.me/j/83/ABC-Marketing-Nov03
simplq.me/j/83/ABC-Technology-Nov05
simplq.me/j/83/ABC-Marketing-Mov08
...

Let me know other ways around this, if you can come up with. Can the hash function generate human friendly short names without collision?

Else can we generate shorter ids like how other url shortness does it? Then we can use it instead of our long UUID for queue IDs directly and then relax requirement (2).

[Trinankur]

I was thinking of prepopulating 6 - 8 char long randomly generated base64 keys and keeping them in the db, which we can associate with the queues as and when created. This could prevent collisions.

When a queue is deleted we can remove the association with key and the key will be available to associate with a different queue. Let me know what do you think.