Skip to content
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

[FEATURE] Utilize built-in search #38

Open
aubiyko opened this issue Mar 23, 2020 · 5 comments
Open

[FEATURE] Utilize built-in search #38

aubiyko opened this issue Mar 23, 2020 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@aubiyko
Copy link

aubiyko commented Mar 23, 2020

Built-in DataTables search does send correct JSON to server with non-empty search property, but it seems the library simply ignores it. Since search itself is provided, I see this as missed opportunity rather than bug.

Your example provides external search facilities instead, but that requires developer interference in JS search handler or server-side controller/API endpoint. Having that done by library itself will be appreciated.

To reproduce:

  1. Use Demo;
  2. Modify wwwroot/js/app.js: add f option somewhere into 'dom';
  3. Observe that built-in search triggers loading data popup but does nothing.
@aubiyko aubiyko added the enhancement New feature or request label Mar 23, 2020
@fingers10
Copy link
Owner

You can add the f to the dom property and make use of the built in search instead of using external search. But the question is against which column you will search the user input? That's why I have removed f from dom in my demo as this package is focused on individual column based search based on datatype.

You can do something similar like what I have suggested in #29 but in a different way as shown below,

if (!string.IsNullOrWhiteSpace(param.Search.Value))
{
    var dtColumn = new DTColumn
    {
        Name = "co", // search operator
        Data = "Name", // column name
        Search = new DTSearch
        {
            Value = param.Search.Value // built-in search value
        },
        Orderable = true,
        Searchable = true
   };

   param.Columns[1] = dtColumn;
}

Note that here I'm explicitly making the search against Name column with the input entered by user from built-in search textbox. You can make use of this param.Search.Value to make search against any column of your wish by following above approach.

Unlike JavaScript this cannot be done automatically as different columns have different datatypes and casting will fail in C#. Lets say you can search the same text against int or DateTime field as it will throw exception. Hence this option is not implemented in the package.

Hope this helps.

Give a star if you like this library.

KR,
Abdul Rahman

@aubiyko
Copy link
Author

aubiyko commented Mar 26, 2020

Unlike JavaScript this cannot be done automatically as different columns have different datatypes and casting will fail in C#.

Server-side library could mimic the behaviour of client-side, that is threat everything as string and perform word-bound search with partial matching.

@fingers10
Copy link
Owner

fingers10 commented Mar 26, 2020

This does a database level search and the SQL formed on the fly for all columns of different type cannot be casted to string. Even if we do so it will sometimes end with doing the evaluation on the code level than in the database level which will have huge performance impact.

@aubiyko
Copy link
Author

aubiyko commented Mar 27, 2020

SQL formed on the fly for all columns of different type cannot be casted to string.

I've conducted some tests and can't confirn this behavior. Signed and usigned byte, signed and unsigned int, signed long, signed and unsigned short, single and double and even datetime works via simple ToString().Contains(needle). String ToString().Contains() doesn't work, but just Contaings() do.

Even if we do so it will sometimes end with doing the evaluation on the code level than in the database level which will have huge performance impact.

By EF.Core defaults, client-side evaluation requires additional actions.

@fingers10
Copy link
Owner

Even if casting is possible why to do unnecessary casting to string for all data types?

I actually thank you for the suggestion, i think that is a great ideal, i will look at adding it to the roadmap.

If you would like to contribute this as a Pull Request, i would be happy to accept it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants