On Aug 23, 2008, at 7:56 PM, Remy Blank wrote: > Mr. Meitar Moscovitz wrote: >> In fact, do you know if implementing this is something that would, >> indeed, be "relatively easy"? If so, I think I might have a go at >> implementing it myself since my team uses this whole "subticket/ >> superticket" concept rather extensively now (and I'd like to avoid >> just the situation you describe). I'd be happy to supply a patch, >> too, if it's of interest to others--I just don't want to start >> down this path if other, more experienced Trac folks think this is >> a waste of effort or would be biting off more than I could chew as >> a green Trac developer. > > I'm practically as green as you are on that particular subject, so > I'm no help there. But if you need it and are willing to share, > please go ahead!
Oh, darn. Looks like I'll have to get my hands dirty after all. :) … So, about 15 minutes or so of diving into the Trac source did yield a find at lines 439 through 444 of the trac/ticket/query.py file, which (at least at first blush) seems to be where (some of?) the operators of the query sublanguage are implemented. Unfortunately, it seems that (perhaps due to the database-agnostic philosophy of Trac?) these are implemented not as regex-style searches but simpler ANSI SQL-based LIKE statements with the `%` wildcard. http://trac.edgewall.org/browser/trunk/trac/ticket/query.py?marks=439-444#L437 This has the unfortunate side effect that no word boundary matching can be so easily introduced because, AFAIK, standards-based SQL does not support such a facility. I imagine the implementation would need to catch the result of Query.execute (I think?) and then filter those results via its own word boundary search. :( > You might want to start a new thread with a somewhat more precise > proposal of the feature, to 1) get some feedback on the idea and 2) > facilitate its inclusion and avoid frustration if the work is done > but the feature is rejected (that is, better have it rejected now > than later). > > -- Remy This is a good idea, and I might do this (but probably not tonight, as it's way too late to be writing feature proposals). However, and please pardon my ignorance of Trac development's culture, would this list be the appropriate place for such a feature request or would a Trac enhancement ticket be more appropriate? Won't really make any difference to me, but I'd obviously like to stack the cards for my own feature request in my favor as much as possible. :D Cheers, -- -Meitar Moscovitz Personal: http://maymay.net Professional: http://MeitarMoscovitz.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
