Ticket #90 (closed improvement: fixed)

Opened 4 years ago

Last modified 4 years ago

Wish: search on part of a tag

Reported by: remy Owned by: sebastian
Priority: minor Milestone: 2.2
Component: explorer Version: trunk
Keywords: quicksearch Cc: r.wetzels@chello.nl

Description

If I am correct you can only search for complete tags, not part of a tag. If you search for "eagle" you will not find the tag "long-crested eagle". It should not be that hard to change the search to a LIKE type query (watch out for _ and % in the input if Cake ORM does not escape these already).

Attachments

svn.ticket90.search-on-part-of-a-tag.patch Download (20.9 KB) - added by sebastian 4 years ago.
Initial proposal to search for part of tags

Change History

Changed 4 years ago by sebastian

  • keywords quicksearch added
  • owner set to sebastian
  • status changed from new to accepted
  • milestone set to 2.2

Changed 4 years ago by sebastian

This is a nice feature request!

I would propose to create a special function in the QueryBuilder component (app/controllers/components/query_builder.php) to handle the quick search action. This function would split the input in words and wraps them into the SQL wildcarded values e.g. "%word%". These sql wildcard values are searched in tags, categories, and locations as in the current implementation.

If the quicksearch contains normal wildcards like * (star) and ? (questionmark), the SQL wildcards are used instead without wrapping the sql values with %. E.g. input "bangkok food* plate?" is transformed to 3 sql values: "bangkok", "food%", and "plate_" and finds tags "foodstore" or "food market" or tags with "plate1" or "plate5".

It would be also nice if multiple words could be escaped by quotes which are not splited. E.g the input "'special name' location" are splited to "special name" and "location".

The Search component (app/controllers/components/search.php) could wrap and paginate this quick search...

Changed 4 years ago by sebastian

Initial proposal to search for part of tags

Changed 4 years ago by sebastian

I attachted attachment:svn.ticket90.search-on-part-of-a-tag.patch Download which is an initial proposal to search for a part of tags, categories, location.

  • First it adds a disable validation option for the Search class which is extended by the Search component class on setting/adding parameter values. This allows to set an arbitrary value whithout a validation. It includes test case changes for the Search component class.
  • Than it adds an quicksearch function to the Search component class which breaks the quick search input into words. Currently it is the old behavior but wraps wildcards to each words
  • The QueryBuilder component handles these wildcards of tags, categories and locations and assures the correct SQL condition building
  • The view of the quick search is reduced to 6 hits which meet the criterias
  • The database schema in app/config/sql/schema.php adds and corrects indexes, especially for HABTM tables of tags, categories and locations
  • The UpgradeSchema component is fixed to upgrade tables which do not have any models (like categories_media table)

You can apply and test this patch agains the current trunk (at the time of writing r547) and call setup controller to correct and build the table indexes.

While the current proposal works it lacks definitely on speed. On my system (AMD64 3,2 GHz, 1GB RAM) it takes 5 - 7 seconds until the quick search result is shown of tag / location combination.

Any suggestion, tick and support is welcome.

Changed 4 years ago by remy

When i take the unified diffs and try to patch, it fails on the schema.php.
I patched them by hand.

It says after calling setup that the database is up-to-date, but it did not change the indexes.

Changed 4 years ago by remy

I have not updated the database (indexes) yet, but the search seems to work ok. I do not seem to notice any speed problems for the search on my site (AMD Athlon(tm) Processor 3500+, 1 GB RAM running Debian).

Changed 4 years ago by remy

  • cc r.wetzels@chello.nl added

Changed 4 years ago by sebastian

Thank you for reporting your experience with this patch. Sorry, that the patch messed something up - don't no why?!

I guess you did not discover any speed problems since your image counts is still "low" - so your database query size is smaller than mine. On my local gallery with >13,000 media files it is slow like hell... I'm thinking about it how to improve this issue. If you know a nice solution, let me know.

Changed 4 years ago by sebastian

  • status changed from accepted to closed
  • resolution set to fixed

Applied patch at r549

Note: See TracTickets for help on using tickets.