I have two IMAP SEARCH commands. Can anyone please tell me which one of these is formatted correctly, or if indeed they both are:
Search A:
UID SEARCH NOT DELETED (OR FROM "eBay" (OR SUBJECT "eBay" (OR TO "eBay" (OR CC "eBay" BODY "eBay"))))
Search B:
UID SEARCH (OR FROM "eBay" (OR SUBJECT "eBay" (OR TO "eBay" (OR CC "eBay" BODY "eBay")))) NOT DELETED
One returns the correct results from my inbox, but the other does not. I'm trying to work out if my mail server software is at fault, or the client issuing the command.
Thanks
Those are equivalent ways to express the same search. Both are correct and any correct server should return the same set of messages for both searches.
Somewhat simplified, the following two are different ways to express "tell me which messages have not been read and are about subject ebay":
s1 uid search subject "ebay" unseen
s2 uid search unseen subject "ebay"
A and B is the same as B and A.
These searches may be syntactically the same, but they could have quite different performance.
There are 2 main search clauses, and one of these is actually a search on a bunch of text fields and the body. The other is a very inexpensive flag check (for undeleted messages).
If the server performing the search checks the /Deleted flag first, then it can potentially save itself a lot of work checking the other text fields (especially the body).
A server that naively checks the search clauses in the order given, would be better doing a flag check first (the top search). If there are no deleted messages in the folder it won't make much difference, since the flag check is likely insignificant in terms of cost. But if there are a lot of deleted messages, then the second form of the search could be a lot more expensive, depending on whether the server is smart enough to do cheap tests first.
Which server is it?
Related
As far as I can see in the IMAP RFC, it appears to say that a MODSEQ value is unique to a folder and will never be repeated unless UIDValidity changes. However, I can't see it saying anything about the account as a whole, rather just folders.
My question is, can I use an emails MODSEQ value as a unique value across the entire inbox, or need I define my own unique value, likely something similar to:
let uid = path + MODSEQ
There are no guarantee about uniqueness across folders. This is because some servers don't know much about other folders than the ones they have open at the moment, and it was considered important to make MODSEQ easy to implement for servers.
Yes, you need your own uniqueness value.
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...
I'm not clear about below queries and curious to know what is the different between them even though both retrieves same results. (Database used sports2000).
FOR EACH Customer WHERE State = "NH",
FIRST Order OF Customer:
DISPLAY Customer.Cust-Num NAME Order-Num Order-Date.
END.
FOR EACH Customer WHERE State = "NH":
FIND FIRST Order OF Customer NO-ERROR.
IF AVAILABLE Order THEN
DISPLAY Customer.Cust-Num NAME Order-Num Order-Date.
END.
Please explain me
Regards
Suga
As AquaAlex says your first snippet is a join (the "," part of the syntax makes it a join) and has all of the pros and cons he mentions. There is, however, a significant additional "con" -- the join is being made with FIRST and FOR ... FIRST should never be used.
FOR LAST - Query, giving wrong result
It will eventually bite you in the butt.
FIND FIRST is not much better.
The fundamental problem with both statements is that they imply that there is an order which your desired record is the FIRST instance of. But no part of the statement specifies that order. So in the event that there is more than one record that satisfies the query you have no idea which record you will actually get. That might be ok if the only reason that you are doing this is to probe to see if there is one or more records and you have no intention of actually using the record buffer. But if that is the case then CAN-FIND() would be a better statement to be using.
There is a myth that FIND FIRST is supposedly faster. If you believe this, or know someone who does, I urge you to test it. It is not true. It is true that in the case where FIND returns a large set of records adding FIRST is faster -- but that is not apples to apples. That is throwing away the bushel after randomly grabbing an apple. And if you code like that your apple now has magical properties which will lead to impossible to cure bugs.
OF is also problematic. OF implies a WHERE clause based on the compiler guessing that fields with the same name in both tables and which are part of a unique index can be used to join the tables. That may seem reasonable, and perhaps it is, but it obscures the code and makes the maintenance programmer's job much more difficult. It makes a good demo but should never be used in real life.
Your first statement is a join statement, which means less network traffic. And you will only receive records where both the customer and order record exist so do not need to do any further checks. (MORE EFFICIENT)
The second statement will retrieve each customer and then for each customer found it will do a find on order. Because there may not be an order you need to do an additional statement (If Available) as well. This is a less efficient way to retrieve the records and will result in much more unwanted network traffic and more statements being executed.
What are the benefits of
http://www.example.com/app/servlet/cat1/cat2/item
URL
over
http://www.example.com/app/servlet?catid=12345
URL
Could there be any problems if we use first URL because initially we were using the first URL and change to second URL. This is in context of large constantly changing content on website. Here categories can be infinite in number.
In relation to a RESTful application, you should not care about the URL template. The "better" one is the one that is easier for the application to generate.
In relation to indexing and SEO, sorry, but it is unlikely that the search engines are going to understand your hypermedia API to be able to index it.
To get a better understanding in regards to the URLs, have a look at:
Is That REST API Really RPC? Roy Fielding Seems to Think So
Richardson Maturity Model
One difference is that the second URL doesn't name the categories, so the client code and indeed human users need to look up some category name to number mapping page first, store those mappings, use them all the time, and refresh the list when previously unknown categories are encountered etc.. Given the first URL you necessarily know the categories even if the item page doesn't mention them (but the site may still need a list of categories somewhere anyway).
Another difference is that the first format encodes two levels of categorisation, whereas the second hides the number of levels. That might make things easier or harder depending on how variable you want the depth to be (now or later) and whether someone inappropriately couples code to 2-level depth (for example, by parsing the URLs with a regexp capturing the categories using two subgroups). Of course, the same problem could exist if they couple themselves to the current depth of categories listed in a id->category-path mapping page anyway....
In terms of SEO, if this is something you want indexed by search engines the first is better assuming the category names are descriptive of the content under them. Most engines favor URLs that match the search query. However, if category names can change you likely need to maintain 301 redirects when they do.
The first form will be better indexed by search engines, and is more cache friendly. The latter is both an advantage (you can decrease the load on your server) and a disadvantage (you aren't necessarily aware of people re-visiting your page, and page changes may not propagate immediately to the users: a little care must be taken to achieve this).
The first form also requires (somewhat) heavier processing to get the desired item from the URL.
If you can control the URL syntax, I'd suggest something like:
http://www.example.com/app/servlet/cat1/cat2/item/12345
or better yet, through URL rewrite,
http://www.example.com/cat1/cat2/item/12345
where 12345 is the resource ID. Then when you access the data (which you would have done anyway), are able to do so quickly; and you just verify that the record does match cat1, cat2 and item. Experiment with page cache settings and be sure to send out ETag (maybe based on ID?) and Last-Modified headers, as well as checking If-Modified-Since and If-None-Match header requests.
What we have here is not a matter of "better" indexing but of relevancy.
And so, 1st URL will mark your page as a more relevant to the subject (assuming correlation between page/cat name and subject matter).
For example: Let`s say we both want to rank for "Red Nike shoes", say (for a simplicity sake) that we both got the same "score" on all SEO factors except for URL.
In 1st case the URL can be http://www.example.com/app/servlet/shoes/nike/red-nice
and in the second http://www.example.com/app/servlet?itemid=12345.
Just by looking on both string you can intuitively sense which one is more relevant...
The 1st one tells you up-front "Heck yes, I`m all about Red Nike Shoes" while the 2nd one kinda mumbles "Red Nike Shoes? Did you meant item code 12345?"
Also, Having part of the KW in the URL will help you get more relevancy and also it can help you win "long-tail" goals without much work. (just having KW in URL can sometimes be enough)
But the issue goes even deeper.
The second type of URL includes parameters and those can (an 99.9% will) lead to duplicated content issue. When using parameters you`ll have to deal with questions like:
What happens for non-existent catid?
Is there a parameter verification? (and how full proof is it?)
and etc.
So why choose the second version? Because sometime you just don`t have a choice... :)
I am using filter as (cn=${prefix}*), where $prefix = 'a'; but still it says 0 records found.
Whereas when I am doing a simple search without this filter, I find many records starting with an 'a'.
here is some part of the code :-
my $prefix = shift();
my $result = $ldap->search ( base => "$ldapbase",
scope => "sub",
filter => "(objectclass=)(cn=$prefix)",
attrs => ['*']
) or die "error searching tree:$#\n";
my $ldapbase gives me details of all the employee, and I want those only which starts with an 'a'.
It might be wise to give the LDAP administrator a heads-up that you intend to be making requests that involve the use of substrings. The LDAP administrator may be able to index CN for substring searches so searches will be faster. The filter '(cn=a*)' is a substring filter, and should return all CN attributes from your search base 'downward' (you're using subtree scope in the example) that start with the letters 'a' or 'A' (CN is probably a DirectoryString type and may not have case sensitivity).
From a practical perspective, some older directory servers require more than one character before the substring '*' character for substring indexes to work, for example '(cn=ab*)' might use indexes on some servers, whereas '(cn=a*)' might not use indexes.
In your code example you list the filter '(objectClass=)(cn=$prefix)', which is not a legal LDAP search filter. Perhaps you meant '(&(objectClass=inetOrgPerson)(cn=${prefix}*))' (inetOrgPerson might be some other object class) and the code listed is a typo. If you want just the DNs of the entries that begin with 'a' or 'A', you can request the 'special' attribute '1.1', that way just the entry DN and no attributes are returned.
When we find our customers searching for CNs that start with a, often times, the next search we see from them is for a CNs that start with aa. Back before we had quite so many users, the next search would be for CNs that start with b.
If you really want to look up all of the entries in the database, there's probably a better way to do that. You may want to talk with your LDAP administrators, it's possible that they have a better way to suggest. LDAP servers, in general, are designed to perform searches that find a small subset of entries, and while they handle queries with larger result sets OK, depending on the exact server software, they may not handle it very well.
There's also the question if whether or not that's really what you want to be doing. Most of the time, the reason our users want to pull all of our entries are because they are administrators of some application that wants to have all the user data in its own database.
Sometimes, these applications can be configured to use an external LDAP in an overlay mode, they just need to be configured to do it. In every case I've been asked to help with a situation like this, the application documentation explicitly said it could do that, but it just wasn't in terms the application administrator recognized as saying that.
Most of the time, the application user base is much smaller than the whole company, and they're trying to pull all of the company's users when they only really need less than 1% of them. Being able to query on something else that just selects the users desired - like (departmentnumber=7159), for example, would generally work much more optimally.