Skip to content

Conversation

@mebezac
Copy link
Collaborator

@mebezac mebezac commented Apr 6, 2015

This is a pull request against the v-0-4-0 branch 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.

@mebezac mebezac mentioned this pull request Apr 6, 2015
@antillas21 antillas21 added this to the v 1.0.0 milestone Apr 7, 2015
@mebezac
Copy link
Collaborator Author

mebezac commented Apr 14, 2015

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.

mebezac added a commit that referenced this pull request Apr 14, 2015
New regex and individual column searching
@mebezac mebezac merged commit 42ca1ec into jbox-web:v-0-4-0 Apr 14, 2015
@mebezac mebezac deleted the new-regex branch April 14, 2015 03:47
Copy link
Collaborator

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

Copy link
Collaborator Author

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:

  1. We iterate over view_columns instead, and insist that the user puts all columns in that array, even if they are not searchable.
  2. 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.

Hopefully this all makes sense.

Copy link
Collaborator

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 :)

Copy link
Collaborator

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?

Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

@ajahongir
Copy link
Collaborator

@JamesChevalier
Copy link

Thanks @ajahongir !

This example project does not contain any instances of regex ... Is there something in datatables.js.coffee that uses this regex search feature?

It looks like line 12 of that file is performing a typical non-regex search. Does that mean it's the default?

@ajahongir
Copy link
Collaborator

@JamesChevalier can you show your sample regexp query please?

@ajahongir
Copy link
Collaborator

It looks like line 12 of that file is performing a typical non-regex search. Does that mean it's the default?

in this example regexp is equal to like query searching in sql. its a default condition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants