Closed featalion closed 11 years ago
cc @edsrzf
It does make sense (at least for me) to unify this part in all client libraries, not only Ruby gem.
This seems fine to me. It doesn't look like anything in the API necessarily needs fixing, but let me know if I'm wrong or that changes.
@edsrzf ya, it does not needs any of API changes, you are right. But I suggested 2 ways how to do right logic. So, question mostly what we want there. Is it simple "call API each time any queue info requested" or "make cache layer and pass all API request thru".
I'd say drop the cache which solves most of this except the first one. Keep the reload method for backwards compatibility too.
For one: "Create new queue and call it for its size:", that method doesn't actually create a cache, it just references a queue, which may or may not exist. We could potentially add a create method: ironmq.queue("x").create to explicitly create it.
@treeder Got it. It seems easy and clear.
Will add the Queue#info
method and update documentation. ironmq.queue("x")
may create the queue if does not exists and return queue info. I think good for that is this POST request. Client library could call it on non-existing queue which creates new queue. It also requires no IronMQ backend changes. Seems more clear, I see no use case when developers can create queue objects but never use them. Again, we provide unlimited number of queues and automatic create seems better in this case for client libraries.
Does it makes sense?
I don't think it should create the queue when you call that method, that would require an extra api hit to check right? I think we should keep that explicit.
It does not for now. For now the gem hits /projects/{Project ID}/queues/{Queue Name}
when Client#queue(name)
is called. So, if we will need to create new queue it takes plus one API call, ofc.
I mean it shouldn't hit any endpoint when you just do ironmq.queue(name) should it?
Yes, this is possible but seems not IronMQ API reflection in this case. If you think we must reduce call numbers it has sense for me. And, ofc, cache is better to do it.
Done. IronMQ::Client#queue(name)
does not call for queue info on IronMQ::Queue
object initialization.
All this points are related to broken caching system for queue information.
The easiest way to fix this just make request to IronMQ API each time user needs any info, except queue's name. Handle HTTP 404 and return "default" value (0 for size, for example). It needs simple updates: drop current caching system and add default for HTTP 404. Requests for info are seems rare and mostly "technical" (not related to logic of application which uses IronMQ) this is may be a good choice.
Another possible solution is to make new caching system. I suggest to use additional layer which wraps all API (iron_core_ruby) calls in
IronMQ::Client
class. This layer must operate with all existing / new queues' info data. Next I place kind of example how it might be realized. Use case:Possible cache realization scheme:
This is simple example of caching system we may implement. We can use self-generated IDs for new queues. This solves that for now we could not get the info on non-existing queues from API. If such system is implemented client library will handle this itself by initializing info structure (size: 0, total_messages: 0, etc.) Cache must store queues' info data structures per name, not ID. This resolves issue with getting HTTP 404 on non-existing queues. Queue cache is initializes on first queue call and shares between all future requests thru the same
IronMQ::Client
object.Also, to reflect API
GET /projects/{Project ID}/queues/{Queue Name}
I suggest to provideQueue#info
method and turn[]
,Queue#id
, etc. work thruinfo
call.What do you think, guys?