Fix a Buggy Spring Boot Movie Search Against Five Search Rules

You are given an existing Spring Boot backend that powers a movie search feature, and the search returns wrong results. The search logic is complicated and spread over several layers. Find and fix the bugs so that the search satisfies all five of these rules: 1. **Partial match**: a movie matches when the search text appears anywhere inside the field being searched, not only when the whole field equals it. 2. **Field choice**: the caller chooses whether to match against the movie title, against the movie's stars (its cast), or against all of these fields. 3. **Case-insensitive**: matching ignores the difference between upper and lower case. 4. **Ordering**: results are sorted by popularity, and then by further keys. 5. **Published only**: a movie that is not published is never returned. ### Constraints and Clarifications - The original codebase is not reproduced here. Assume a conventional layout: a `Movie` JPA entity with an id, a title, a collection of star names, a numeric popularity score and a published flag; a Spring Data repository; a service that implements the search; and a REST controller that receives the search text and the field choice as request parameters. - Fixing the bugs should not change the endpoint's path, parameters or response shape, because existing clients depend on them. ### Clarifying Questions - In "all fields" mode, does a movie qualify when the text matches either the title or any star, or must it match both? - Is popularity sorted with the most popular movie first, and which keys break ties after popularity? The rule only says "and others". - What should a blank or missing search text return: every published movie, nothing, or a validation error? - Is "partial" a plain substring match, or should it also handle word prefixes, accents or typos? - Are results paginated, and may a client override the sort order? ### Part 1 — Turn the rules into failing tests Before changing any code, write the tests that pin down each of the five rules, so that every fix is proven by a test that fails before the fix and passes after it. Describe the test data and the expected result of each test. ```hint Make each test fail for one reason For every rule, choose data where one specific wrong behavior (exact instead of partial matching, a case-sensitive comparison, the wrong field, an unpublished movie, a wrong tie order) changes the result and nothing else does. ``` #### What This Part Should Cover - At least one distinguishing case per rule, including mixed-case text and popularity ties - Interactions between rules, especially the published filter combined with each field choice - Which layer each test exercises (repository, service or HTTP endpoint) and why that matters ### Part 2 — Track down the defects The logic is complicated and spread over the controller, the service and the repository. Explain how you would locate the defects efficiently, which concrete defects you would suspect for each rule, and how you would confirm that the fixes do not break anything else. ```hint Follow one request end to end Trace a single search request from the controller's parameters to the SQL that actually runs, and compare each step with the rule it is supposed to enforce. ``` #### What This Part Should Cover - A systematic way to trace a request through the layers, including inspecting the generated query - Specific suspected defects mapped to each of the five rules - How regressions are prevented once the fixes are in ### Part 3 — Write the corrected search Write the corrected search: the field-choice handling, the partial case-insensitive matching, the published filter and the ordering. Decide whether filtering and sorting run in the database query or in Java, and justify the choice. ```hint Watch how the conditions combine Write the full boolean condition out with explicit parentheses, and check where the published filter sits relative to the "title or stars" alternative. ``` #### What This Part Should Cover - Matching that is partial and case-insensitive for the title and for every star name - A published filter that applies under every field choice - A deterministic order with an explicit direction and tie-breakers - The cost of the chosen approach as the catalog grows ### What a Strong Answer Covers - Every rule restated precisely, with the unresolved ones raised as questions rather than guessed silently - A correct boolean structure, so that no field choice can bypass the published filter - Case-insensitive matching that does not depend on the server's locale - A total, stable sort order that holds across pages - Tests that fail before each fix and pass after it, with no change to the endpoint's contract ### Follow-up Questions - The catalog grows to millions of movies and the substring search becomes slow. What would you change? - How would you add pagination without breaking the ordering or the published filter? - Product now wants accent-insensitive matching and tolerance for small typos. How does the design change?