Send FilterResults Parameter
=====================================================
Problem Description
The search results have switched from being filtered to unfiltered, causing wildcard searches to stop working as expected. For example, an item search for ma??ingly
should return 495 results but started to return 2,371. All 2,371 results were accessible via pagination (i.e., it wasn't just the search estimate). This unexpected behavior has caused issues with the search functionality, and it is essential to resolve this problem to ensure that the search results are accurate and filtered correctly.
Expected Behavior/Solution
The cause of this issue is that the backend added a filterResults
parameter to its search endpoint, yet we didn't add that parameter to the middle tier's call to that endpoint. Since some of the parameters are optional, the backend started processing the middle tier's facetsSoon
parameter value (false
) as the filterResults
parameter, thereby overriding the default of true
. To resolve this issue, we need to update the middle tier's call to the backend's search endpoint to include the filterResults
parameter.
Requirements
To resolve this issue, we need to complete the following tasks:
- Update the middle tier's call to the backend's search endpoint: We need to add the
filterResults
parameter to the middle tier's call to the backend's search endpoint. This will ensure that the search results are filtered correctly. - Update the middle tier's call to the backend's relatedList endpoint: While not likely causing a problem, this endpoint also has the
filterResults
parameter. We should update the middle tier's call to this endpoint as well to ensure consistency. - Review all middle tier calls to the backend: We should review all middle tier calls to the backend to see if we can find any other discrepancies. This will help us identify any other potential issues and ensure that our code is consistent and accurate.
- Consider making all backend parameters required or requiring a single parameter that's JSON: We should consider making all backend parameters required or requiring a single parameter that's JSON and going by property names versus parameter order. This will help us avoid similar issues in the future and make our code more maintainable.
Needed for Promotion
If an item on the list is not needed, it should be crossed off but not removed. This is an essential requirement for the promotion of the search functionality.
Tasks and Dependencies
The following tasks and dependencies are associated with this issue:
- Wireframe/Mockup: Mike is responsible for creating a wireframe or mockup for this issue.
- Committee discussions: Sarah is responsible for leading the committee discussions for this issue.
- Feasibility/Team discussion: Sarah is responsible for leading the feasibility and team discussion for this issue.
- Backend requirements: We need to consider the backend implications of this issue, including making all backend parameters required or requiring a single parameter that's JSON.
- Frontend requirements: There are no frontend requirements for this issue.
- Are new regression tests required for QA: Amy is responsible for determining whether new regression tests are required for QA.
- Questions: We should document any questions or concerns related to this issue.
UAT/LUX Examples
The following UAT/LUX examples are relevant to this issue:
- Simple search for
ma??ingly
objects: We should test the search functionality with a simple search forma??ingly
objects to ensure that it is working correctly.
Dependencies/Blocks
The following dependencies and blocks are associated with this issue:
- Blocked By: There are no dependencies that block this issue.
- Blocking: This issue is blocking the frontend from receiving filtered search results.
Related Github Issues
The following related Github issues are associated with this issue:
- **https://github.com/project-lux/lux-marklogic/issues/223**: This issue introduced the
filterResults
parameters in the backend endpoints.
Related Links
There are no related links associated with this issue.
Wireframe/Mockup
There is no wireframe or mockup associated with this issue.
Solution
To resolve this issue, we need to update the middle tier's call to the backend's search endpoint to include the filterResults
parameter. We should also update the middle tier's call to the backend's relatedList endpoint to ensure consistency. Additionally, we should review all middle tier calls to the backend to see if we can find any other discrepancies. Finally, we should consider making all backend parameters required or requiring a single parameter that's JSON to avoid similar issues in the future.
Code Changes
The following code changes are required to resolve this issue:
// Update the middle tier's call to the backend's search endpoint
public void search(String query) {
// Add the filterResults parameter to the request
Map<String, String> params = new HashMap<>();
params.put("filterResults", "true");
// Make the request to the backend
Response response = makeRequest(query, params);
// Process the response
}
// Update the middle tier's call to the backend's relatedList endpoint
public void getRelatedList(String query) {
// Add the filterResults parameter to the request
Map<String, String> params = new HashMap<>();
params.put("filterResults", "true");
// Make the request to the backend
Response response = makeRequest(query, params);
// Process the response
}
Testing
We should test the search functionality with a simple search for ma??ingly
objects to ensure that it is working correctly. We should also test the relatedList endpoint to ensure that it is working correctly.
Conclusion
In conclusion, the search results have switched from being filtered to unfiltered, causing wildcard searches to stop working as expected. The cause of this issue is that the backend added a filterResults
parameter to its search endpoint, yet we didn't add that parameter to the middle tier's call to that endpoint. To resolve this issue, we need to update the middle tier's call to the backend's search endpoint to include the filterResults
parameter. We should also update the middle tier's call to the backend's relatedList endpoint to ensure consistency. Additionally, we should review all middle tier calls to the backend to see if we can find any other discrepancies. Finally, we should consider making all backend parameters required or requiring a single parameter that's JSON to avoid similar issues in the future.
=====================================
Q: What is the filterResults
parameter?
A: The filterResults
parameter is a parameter that is added to the backend's search endpoint to filter the search results. It is used to determine whether the search results should be filtered or not.
Q: Why is the filterResults
parameter causing issues?
A: The filterResults
parameter is causing issues because it is not being added to the middle tier's call to the backend's search endpoint. As a result, the backend is processing the middle tier's facetsSoon
parameter value (false
) as the filterResults
parameter, thereby overriding the default of true
.
Q: What are the requirements to resolve this issue?
A: The requirements to resolve this issue are:
- Update the middle tier's call to the backend's search endpoint: We need to add the
filterResults
parameter to the middle tier's call to the backend's search endpoint. - Update the middle tier's call to the backend's relatedList endpoint: We should update the middle tier's call to the backend's relatedList endpoint to ensure consistency.
- Review all middle tier calls to the backend: We should review all middle tier calls to the backend to see if we can find any other discrepancies.
- Consider making all backend parameters required or requiring a single parameter that's JSON: We should consider making all backend parameters required or requiring a single parameter that's JSON to avoid similar issues in the future.
Q: What are the benefits of resolving this issue?
A: The benefits of resolving this issue are:
- Improved search functionality: Resolving this issue will improve the search functionality by ensuring that the search results are filtered correctly.
- Reduced errors: Resolving this issue will reduce errors caused by the
filterResults
parameter not being added to the middle tier's call to the backend's search endpoint. - Improved user experience: Resolving this issue will improve the user experience by providing accurate and filtered search results.
Q: What are the potential risks of not resolving this issue?
A: The potential risks of not resolving this issue are:
- Continued errors: If the issue is not resolved, the errors caused by the
filterResults
parameter not being added to the middle tier's call to the backend's search endpoint will continue. - Decreased user satisfaction: If the issue is not resolved, the user satisfaction will decrease due to the inaccurate and unfiltered search results.
- Increased maintenance costs: If the issue is not resolved, the maintenance costs will increase due to the need to constantly fix the errors caused by the
filterResults
parameter not being added to the middle tier's call to the backend's search endpoint.
Q: What are the next steps to resolve this issue?
A: The next steps to resolve this issue are:
- Update the middle tier's call to the backend's search endpoint: We need to add the
filterResults
parameter to the middle tier's call to the backend's search endpoint. - Update the middle tier's call to the backend's relatedList endpoint: We should update the middle tier's to the backend's relatedList endpoint to ensure consistency.
- Review all middle tier calls to the backend: We should review all middle tier calls to the backend to see if we can find any other discrepancies.
- Consider making all backend parameters required or requiring a single parameter that's JSON: We should consider making all backend parameters required or requiring a single parameter that's JSON to avoid similar issues in the future.
Q: Who is responsible for resolving this issue?
A: The following individuals are responsible for resolving this issue:
- Mike: Mike is responsible for creating a wireframe or mockup for this issue.
- Sarah: Sarah is responsible for leading the committee discussions for this issue.
- Amy: Amy is responsible for determining whether new regression tests are required for QA.
Q: What are the dependencies and blocks associated with this issue?
A: The following dependencies and blocks are associated with this issue:
- Blocked By: There are no dependencies that block this issue.
- Blocking: This issue is blocking the frontend from receiving filtered search results.
Q: What are the related Github issues associated with this issue?
A: The following related Github issues are associated with this issue:
- **https://github.com/project-lux/lux-marklogic/issues/223**: This issue introduced the
filterResults
parameters in the backend endpoints.
Q: What are the related links associated with this issue?
A: There are no related links associated with this issue.