fix : pagination_and_Filtering_for_Lists-2

[akshit-git24]

Hi @sr-857 ,
I refactored the get_analyses endpoint to make it more robust for our frontend integrations and scalable for larger datasets. This update addresses potential performance bottlenecks and improves the developer experience by providing clearer pagination details.

Key Changes:

1.) Smart Pagination: The response now wraps the list of items with metadata (total_count, has_next), so the frontend knows exactly when to show a "Load More" button or how many pages exist.

2.) Performance Safeguards: Implemented a hard limit of 100 items per request. Attempting to fetch more than that now returns a helpful 400 Bad Request instead of silently straining the database.

3.) Consistent Ordering: Fixed potential "page drift" issues. Results are now sorted by created_at and a unique id, guaranteeing that items won't jump around between pages if they have the same timestamp.

4.) Schema Updates: Updated AnalysisListResponse and PaginationMetadata to reflect these changes in our API contract.

Breaking Change:

1.) The response format for GET /analysis has changed:
Before: [ { ...analysis }, ... ]
After: { "items": [ ...analysis ], "metadata": { "total_count": 50, "has_next": true, ... } }

Thanks for the issue assignment. This branch is ready to merge cleanly.

Don't merge this until my next commit or comment, i need to check is there any other change that increase the performance of the system!

[akshit-git24]

Hi , i found one more concern , not for the backend system but for the db.

THe issue is when you search for text (like title or description) without a database index, the database has to scan every single row in the table to find matches. This process becomes very slow as the database grows because it uses linear search type.

I'll optimise this ASAP.

[akshit-git24]

okay, @sr-857 i improved the performance of api to search by index that improves the db responses.

Thank you! Now this branch is safe to merge