Sorting Gmail threads by date - swift

I'm hoping someone can suggest a good technique for sorting Gmail threads by date without needing to get details on potentially thousands of threads.
Right now I use threads.list to get a list of threads, and I'm using whatever order they're returned in. That's mostly correct in that it returns threads in reverse chronological order. Except that chronology is apparently determined by the first message in a thread rather than the thread's most recent message.
That's fine for getting new messages at the top of the list but it's not good if someone has a new reply to a thread that started a few days ago. I'd like to put that at the top of the list, since it's a new message. But threads.list leaves it sorted based on the first message.
I thought the answer might be to sort threads based on historyId. That does sort by the most recent message. But it's also affected by any other thread change. If the user updates the labels on a message (by starring it, for example), historyId changes. Then the message sorts to the top even though it's not new.
I could use threads.get to get details of the thread, and do more intelligent sorting based on that. But users might have thousands of threads and I don't want to have to make this call for every one of them.
Does anyone have a better approach? Something I've missed?

I'm not a developer and never used the API before but I just readed the API documentation and it doesn't seem to have the functionality you want.
Anyway, this is what I understood in your question:
You want is organize threads by the latest message in each one.
I thought you could use a combination of users.messages and threads.list. In users.messages you'll have the ThreadID:
threadId string The ID of the thread the message belongs to.
The method would be using the date of user.messages to organize the latest messages from newer to old, then recursively obtain their original threads by threadId and print the threads with threads.list by their latest received message.
With this method you'll avoid recursion in each thread saving resources and time.
I don't know how new messages are affected by labels or starring, you'll have to find out that.
I apologize in advance if my answer isn't correct or missleading.

Related

How to manage a pool via a RESTful interface

As I am not sure I stated the question very well originally, I am restating it to see if there is a better response.
I have a problem with how best to manage a specific kind collection with a RESTful API. To help illustrate the issue I have I will use an simple artificial example. Lets call it the 'Raffle Ticket Selector'. For this question I am only interested in how to perform one function.
I have a collection of unpurchased raffle tickets (raffleTickets). Each with a unique Raffle Number along with other information.
I need to be able to take an identified number of tickets (numTickets) from the raffleTickets collection without uniquely selecting them. The collection itself has a mechanism for random selection.
The result is that I am returned 5 unique tickets from the collection and the size of the collection is decreased by 5 as the 5 returned have been removed.
The quesition is, how do I do it in a RESTfull way?
I intuatively want to do METHOD .../raffelTickets?numTickets=5 but struggle with which HTTP Method to use
In answering; you are not allowed to suggest that I just PATCH/PUT a status change to effect a removal by marking them taken. It must result an actual change in the cardanality of the collection.
Note: Calling the method twice will return a different result set every time and will always alter the collection on which it is performed (unless it is empty!)
So what method should I use? PUT? POST? DELETE? PATCH? Identpotent restrictions would seem to only leave me with POST and PATCH neither of which feels ideal to me. Or perhaps there is another way of providing the overall behavior that is considered the correct approach.
I am really interested to know what is best practice and understand why.
Cheers
Original Post on which the first response was based:
I have a pool of a given item which is to be managed with a RESTful API. Now adding items to the pool is not an issue but how to I take items from the pool? Is it also a POST or is it a DELETE?
Lets say it is a pool of random numbers and I want to retrieve a variable number of items in a single method call.
I have two scenarios:
I am not checking them out as once taken they will not be returned to the pool.
I only want to check them out and they effectively remain part of the pool but have a status altered to 'inUse'
The important thing in each case is I do not care which items I get, I just want N of them.
What is considered the RESTful way performing each of the two actions on the pool? I have an opinion on the second option but I dither on the former so I am interested in your thoughts for both so I better understand the thought pattern
Thanks
Not sure if I understood well your question. It will mostly depend on the way you developed the API side of your REST communication.
In a generic solution, you would use DELETE to take items out of a list. However, if you just want to PARTIALY update the items, you could use PATCH instead of POST or PUT.
Give this a look: http://restcookbook.com/HTTP%20Methods/patch/

Quotes and HandlInst <21> field in FIX protocol

I'm trying to understand the variety of message types and data fields in FIX protocol.
I did understand most of the things but I'm still not sure about Quotes and HandlInst.
When a dealer or a broker wants to trade in the market he have a list of all available products (e.g USD/EUR, USD/JPN, ...). each product has sell-price and buy-price which being update in high rate. Which message type generates this values? A Quote message type(quote request and quote response)?
A broker have the option to decide for each one of his dealers whether he automatically response as the counter-party for the dealer orders or the orders go out to the market for a trade. Which filed in the order message types indicates that mark? I was thinking about HandlInst <21> but i'm not quite sure...
Thanks for your help
These are vendor-specific questions. FIX just gives you a pile of messages and fields you can use, and some recommendations for how to use them. Some counterparties even follow those recommendations, but nearly all of them add their own weird customizations or use certain fields in weird ways.
If you are connecting to an external counterparty, you need to read their docs for their specific FIX interface. That will tell you which fields they use, how they use them, and what they expect from you.
So, get your counterparty's docs and read them.
Ok Kitsune, here are my answers for you (you should pay me for this !)
yes, Quote, and QuoteCancel (usually)
I think you are talking about an internal broker decision that's not to do with FIX. HandlInst can be used by a client sending their order to the broker to specify manual or automatic execution, but I think that is in specific limit order cases only, not the usual fill or kill stuff. If the order was $100mio then maybe a client would specify manual execution. Again, as in your other post, the ExecutionReport can specify manual or auto execution as well. Need to look at that...

How to model very large work queues in Akka?

I am writing a scala script to download all items from the hacker news API. There are ~12M items, each being a JSON of ~200 bytes.
I identified the following issues:
Storing the data: I tried to save each item as a single JSON file, but it became very hard just to barely list them (using Linux, ext4 file system). So I changed it to just append JSON items to multiple (100) files (by taking the item's id module 100).
Keeping track of what has been downloaded, because I want to be able to stop/continue the application. First I tried writing the downloaded ids to a textfile, but it turned out a little bit buggy. So now I just read all the items and collect the ids. (It works.)
All this is done with 1 Master actor and an arbitrary number of Worker actors (tens). The Master has a Queue[Int] and pops it and Workers ask for work.
The problem I am having is fairly simple but I haven't been able to solve it in a nice way.
I can collect the ids from items already downloaded in a list. But what I really need is the complement to that set; I need all the items I have not downloaded, up to the highest item id.
I tried using a range (1 to maxItemId) and subtracting the set of done jobs but it is really slow. reaaaaaaally slow.
Now I am using a Stream, and when a worker asks for a job, I check if the stream's (the next job) has already been done. If so, I give it to the Worker. Otherwise I check the next one.
The problem with this approach is that I can not put jobs back at the stream if they fail. That would be easy with the Queue; but then again I am having trouble just setting up the queue with millions of items.
What could be a better approach to this? I don't think the issues here are trivial, this is a very large number of tasks to perform and keep track of, but it shouldn't be so hard as well.
Thanks!
As far as I understood your question, I think you don't need a very complicated data structure here.
Assuming your ids are sequential from 1 to maxItemId, you can use an array of Boolean with maxItemId size to keep track of processed items. You initialize this array by reading the processed ids. And you find the next job by searching for the next false entry.
Assuming that your maxItemId is around 12M, iterating over all items is pretty much instantaneous.

ExecuteGet do not return the updated value from couchbase server

We use couchbase server 2.2.0 in our production application.
In the last couple of month , when we ExecuteGet on a value, we get the previous value instead of the updated one.
Example scenario (all the actions are synchronized):
UserBalance_12345 is 500.
1. ExecuteSet("UserBalance_12345",1000)
2. ExecuteGet("UserBalance_12345"); -> The result is 500 instead of 1000.
This scenario occur very rarely but still happen and make damage to us because people say their balance is not updated immidietly.
How can such a scenario happen in couchbase?
Do you have a solution for this scenario?
A long time ago, I've also expirienced this issue. Sometimes it returned incorrect values. There are also some forum topics about this. But in my case that data wasn't so important and that issue raised very rarely, so I actually don't tried to figure out what causes it. And this issue is related .net sdk, because i.e. in nodejs sdk with js callbacks it never happend to me.
But I have sevral ideas that may help you.
1) Try to add to your ExecuteStore persist parameter:
PersistTo persistTo = PersistTo.One;
var result = _Client.ExecuteStore(StoreMode.Set, key, value, persistTo);
2) If you store user balance in separate key (just like in question) and it's type fits to ulong you can try to use Increment or ExecuteDecrement function instead of ExecuteStore. Increment/decrement functions are usally work better than store and they are atomic.

abort a fetchRequest in managedObjectContext

I have a fetchRequest which takes up to 4-5 seconds to finish. Since it is part of a search-as-you-type solution, is there any way to abort a fetchRequest?
I use a timer set to start searching my database after 600ms after the user ended typing. So there is a possibility that a new search has to start before the old one has finished.
I haven't found any methods for the NSMangedObjectContext that seem to be right. Is simply setting the old fetchRequest = nil the way to go? Or is there still something going on in the background?
Any ideas?
Thanks in advance!
PS: I'm also trying to enhance my query speed. Maybe someone has an idea for that too:
https://stackoverflow.com/questions/4695729/query-performance-with-large-database
Better way is a place limit for fetch request objects.
(void)setFetchLimit:(NSUInteger)limit
Parameters
limit
The fetch limit of the receiver. 0 specifies no fetch limit.
Discussion
Special Considerations
If you set a fetch limit, the framework makes a best effort, but does not guarantee, to improve efficiency. For every object store except the SQL store, a fetch request executed with a fetch limit in effect simply performs an unlimited fetch and throws away the unasked for rows.
Assuming you're using a UITextField for the text entry, why don't you move your fetchRequest logic to the textField:shouldChangeCharactersInRange:replacementString: (UITextField) delegate method?
This method is called every time a user enters or deletes a character from the textfield, so it is the perfect place to check for a minimum number of characters before firing off a fetch request, as well as changes to the text that would require you to set the existing fetchrequest to nil and start a new one.
I don't think you can, since it almost certainly ties up the thread doing the fetch. The last time I needed to do something like this, I spawned a background thread, with a basic condvar (NSCondition) to signal when a new input was available, and -performSelectorOnMainThread:... to signal when the output was ready. This means that the background thread will continue to work on out-of-date inputs for a while before picking up the new "most recent" input.
You can probably do a similar thing with NSOperation/NSOperationQueue by cancelling all operations on the queue (representing old inputs) before adding a new one (representing the latest input).
Since NSMO/NSMOC isn't thread-safe, you probably want to pass the set of (the first few) MOIDs instead.