Custom keys or pattern keys

[nomi-ramzan]

Is there any way to create or define custom task key or define pattern/prefix for each task ?
For examples app1:user1:jobtypeA:{serial} where serial can be a hash like before or any integer number
Thank you

[nomi-ramzan]

my solution is failing on deleteMessage function because of RegExp /^([a-zA-Z0-9:]){32}$/ used at this validation.

[smrchy]

Your solutions messes with the ordering of the messages which should not happen.

The message ids generated should really not matter to your application. You will receive the ID on a sendMessage and use it to delete / finish the message. Why would you need custom ids here?

[nomi-ramzan]

if i want to query on tasks like in my example above

app1:user1:jobtypeA:{serial}

I can query how many tasks are pending for app1 or app1:user1 in this case how can i query these tasks ?

[smrchy]

You can't and you should not!

If you need that functionality you should

• use different queues - e.g one for each app.
• use some other tool to keep track of your messages (a database)

Let's say you need to get all messages for user1 because the user gets deleted and you need to delete all his messages. Then your application should simply discard every message for user1. That's way more elegant than finding all messages and delete them.

RSMQ is a message queue. And should be used as a message queue. It's not a database that listens to queries (all messages where x=y) or something like that.

[nomi-ramzan]

Thank you for explanation. But don't you think this can help users to track or at least get the idea like user1:app1 has 10 task pending tasks and user1:app2 has 20 tasks pending. even little bit more complex can be user1:app1:tasktype1 and user1:app1:tasktype2 ? if I will use your technique there will be many active queues and on user deletion i need to scan all queues related to one user and than have to delete them. what do you think about it ?

[smrchy]

I sure see that this might help in your described case. But this is not what this project is about. The S in RSMQ stands for simple. If i would create all of your mentioned query capabilities i would have to make a lot of changes for this specific case and the data structures in Redis would become a lot more complicated. Something i'm sure must be avoided.
I am sure in your specific case there is a way to solve your problem in a more elegant way than to add complexity to this module. I doubt you should query a message queue for this.

[nomi-ramzan]

Thank you for your time.