Please forgive my naïveté, but after a brief look through the new v3 API I fail to see why the inclusion of "(YEAR)" in the movie title search string fails to bring any results. I understand that this extra data is not necessarily part of a movie title, but why does the search function being called by the API attempt to perform an exact match on the search string? Why does performing the same search on your site also return no results? Why is this new version of search so limited?

Please forgive my naïveté

That's ok, I don't mind elaborating for you.

I fail to see why the inclusion of "(YEAR)" in the movie title search string fails to bring any results.

Solr can search for text numerous different ways but when it comes to doing a "full text" search it uses a combination of different filters (both at indexing and query time) to build different terms and positions of those terms to assume a match. In the case of adding a year, it's enough of a difference between the original title with no year (indexed value) and title plus year that Solr deems them too different to be a match.

This is why you can also query fields. So in the event of someone searching for a year, you can query two things at once. Movies that match "star wars" but ALSO have the year 1977. Before our upgrade, the search was very naive. We simply looked for 4 digits at the end of any string, assumed it was a year and passed the query term + year field back to Solr. The problem with this method is that there are a number of movies that end in 4 digits, like Mr. 3000 or Blue Brothers 2000. This is hardly ideal, we're doing a lot of assuming here. What if "the next" Avatar has 4 digits in it? Uh oh.

Because of this, back when we launched v3 (November 2011) I made the ability to search for a year a discrete parameter. So instead of doing this:

?query=star+wars+1977

You would do this:

?query=star+wars&year=1977

For an API, this is a perfectly good option. The benefit here is that depending on the app, they can build the year search in however they want. Whether it's a file name parser, a drop down in a UI or human input, I'll leave that decision to the app. The main thing that is important on our end is can someone enter "Mr. 3000" and find a hit? Yes, they can.

Taking this one step further, if you think of the TMDb website as just another client to the API (which it is about 50% of the time) how does one specify a year then? Well, I made my own syntax and parser for that:

star wars y:1977

When v3 was released 18 months ago, one of the important changes we made was that it didn't try to "hack" together logic. Consistent behaviour is very important. Everything in v3 is an attempt to be nice and clear and separated for any developer to build whatever they can dream up. This is an important thing to remember as the way the API implements different things is not (and should not) be the end users problem. It's up to the developer consuming our API to build YOU a better tool.

Hope that helps explains some things.

P.S.

Why is this new version of search so limited?

It's not. In this overhaul I fixed over 10 searching issues that affected every day searches. This search is many, many times better.