-
Notifications
You must be signed in to change notification settings - Fork 227
New regex and individual column searching #97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
I'm just going to go ahead and merge this, it has a bit of refactoring, a fix, and the new Regex stuff. We can just iterate on top of the Regex stuff later. |
New regex and individual column searching
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thinking we actually need searchable_columns here, given not all columns will be marked as searchable when coming in from the params hash that the plugin provides.
You can see the current implementation of searchable_columns here: https://github.com/antillas21/ajax-datatables-rails/blob/v-0-4-0/lib/ajax-datatables-rails/base.rb#L42-L45
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's actually why we need view_columns, because the params[:columns] array will have all the columns that are present in the view.
For example, say you have 5 columns on the view. Columns 0, 1, 2, and 4 are searchable, but 3 is not. Your searchable_columns will have four elements. But your view_columns will have 5 elements if you correctly set it up.
Now in the view you search on column 4 (the fifth one). This method would iterate over the 4 searchable_columns while checking the index against the 5 params[:columns]. It would never reach the last column, and therefore not search against it.
So I guess we could handle this 2 ways:
- We iterate over
view_columnsinstead, and insist that the user puts all columns in that array, even if they are not searchable. - Perhaps better, we iterate over
searchable_columns, but also filter out the columns fromparams[:columns]that are searchable and check for their value at that index.
Hopefully this all makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that's completely accurate... we don't need an index for searching columns, searchable_columns will return an array of columns to build our where conditions.
So, in your example where columns 0,1,2,4 are searchable and 3 is not (collected from the columns description via the params hash), using the searchable_columns method will yield us precisely that: columns 0,1,2,4 and so, we then already have the actual columns to build our where clause(s), so it's safe to only iterate them.
This is, we only need the ModelName.field_name from a pre-filtered columns array, based on whether their description says they're searchable = "true" or not.
Keeping track of the actual column index is important only for sorting purposes, I think. But is really not needed for filtering records... here we can collapse all view_columns into those which really are described as searchable by the params hash.
Hope to make sense :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, by using the whole view_columns array here... we'll be ignoring the columns description coming from the params hash... again, from your example where columns 0,1,2,4 are searchable and 3 is not... by using view_columns we'll be using all columns (0,1,2,3,4) to build our where clauses... then, what would be point to mark 3 as non-searchable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LOL... NO, NO.... forget all my arguments 😄
I have realized the difference now... it all makes sense. self facepalm.
You're COMPLETELY right, we need view_columns here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
haha 😃 no worries! I think though option #2 from above:
Perhaps better, we iterate over searchable_columns, but also filter out the columns from params[:columns] that are searchable and check for their value at that index.
would be a good thing for me to put together. That way, we can iterate over an array of the params[:columns] that only contains the ones that are searchable, thus saving a couple useless iterations. Plus having a method that grabs the params of the searchable columns (and another for sortable) would probably be handy to have anyways.
|
here is emaple project - |
|
Thanks @ajahongir ! This example project does not contain any instances of It looks like line 12 of that file is performing a typical non-regex search. Does that mean it's the default? |
|
@JamesChevalier can you show your sample regexp query please? |
in this example regexp is equal to |
This is a pull request against the
v-0-4-0branch that fixes searching on individual columns and introduces regex searching (Must be using PG for database).I can add some documentation and new tests (I'll need to have a separate spec that uses PG as the database) later if you wish.