Needs work
Project:
Localization server
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
15 Oct 2009 at 11:55 UTC
Updated:
6 Apr 2011 at 17:36 UTC
Jump to comment: Most recent file
Comments
Comment #1
gábor hojtsyThis code fragment pretty much shows why this approach fails badly. If we use LOCATE(), the database will need to run this function on each row, which prohibits using any indexes.
I'd say we'd rather cache this data in a column and do this calculation only once when the source string is inserted into the database.
This review is powered by Dreditor.
Comment #2
claudiu.cristeaThat was my first thought but I didn't want to alter the table structure...
Comment #3
claudiu.cristeaHere's a patch reflecting #1.
Comment #4
claudiu.cristeaThe above patch is incomplete... Use this one.
Comment #5
claudiu.cristeaAdded also filtering on the moderation page.
Comment #6
gábor hojtsyMuch better direction IMHO! The patch does not add the field to fresh installs though.
Comment #7
claudiu.cristeaYou're right. Here's the fix...
Comment #8
claudiu.cristeaForgot the the ticket status...
Comment #9
podaroksubscribe
Comment #10
gábor hojtsyRetitled. There are basically two things which make me hesitant to load in more filters: #581342: String filter form too wide and that the indexes on the tables are not performing well for the current wide ranging filters already (think database query performance). It is probably not possible to optimize for use of arbitrary filters, so we need to balance flexibility and speed.
Comment #11
claudiu.cristeaIt seems an important improvement in terms of usability... at least for me :)
Getting to the point...
Comment #12
gábor hojtsyOk, I think the latest UI changes make it possible to add these filters more easily. Let's do it.
Comment #13
gábor hojtsyAdded #1118430: Set up the filtering/display setting UI for future growth to set us up for filter extensions like this.