Then using the Quick CRUD Wizard picked the table, search field etc to create a page.
When I use the “Filter” checkbox in the data_table, it only filters for values that are on the screen.
The table has 20,000 rows and I want to filter for all those rows, using a MySQL query for the full Filter setup created on the screen
Thanks @pranav .
I appreciate you reading the post.
I have already spent a lot of time trying all samples, posts, medium posts etc.
What I am asking for is pretty common.
Any database worth calling a database will have more than a few hundred rows, so the current data grid and filter in Appsmith really is not of much use if it only uses client-side filtering.
However the UI that you have built for “multiple selection of filters” is great and it is exactly what is needed for powerful filtering.
The ideal solution would be to repurpose that UI to perform server-side filtering.
I am referring to this UI element for FIlters
The proposed solutions such as Server side filtering - How do I do X? - Appsmith
of building your own select box and using that to filter breaks down once you want to filter using multiple columns.
If a table has 10 columns, trying to build and place 10 select boxes and then build additional checkboxes for AND, OR connections between the filters would take away from the principle behind low-code tools.
Might I humbly suggest that you explore using the existing filter builder and exposing the “query” it builds to a server side query and filter.
eg if using the UI, I built a filter like
email contains ‘amazon.com’ OR companyname contains ‘amazon’ AND customer = ‘y’ AND year contains ‘2022’ (you get the idea)
Could I get access to the output of this build which I could later pass into a SQL query which is similar to perform the server-side filtering?
What you have built is already 95% there and to suggest hand crafting a whole new UI using select boxes and checkboxes would suggest a massive step backwards.
Hope what I am suggesting is clear.
Thanks for building a great product and making it available.
@trey this is a great suggestion and definitely on the cards for us to implement. I think we’ve largely figured out a way forward for most DB Queries but we’re still figuring out how to make it work for APIs.
