Mr. Meitar Moscovitz wrote: > On Aug 24, 2008, at 4:37 PM, Remy Blank wrote: > >> Mr. Meitar Moscovitz wrote: >>> Noah, you mentioned: >>>> This was exactly how the 0.10 version of the plugin tried to >>>> work, just using some funky SQL to pull data from a semi- >>>> formatted text field. This didn't work well at all, hence the >>>> massive warning against using that iteration of the plugin. >>> Do you mean to say that the TracLinks-style ticket-as-keyword is >>> something that was tried but "didn't work well at all"? Apologies, >>> I'm not following your meaning…maybe I need my coffee worse than I >>> thought. >> I don't think so. He's referring to the way the plugin stores the >> ticket relations. There were two major revisions of the >> MasterTicketsPlugin: the 0.10 version and the 0.11 version. The >> former used a custom ticket field with a space-separated list of >> ticket numbers as the storage mechanism, and references were >> extracted with "funky SQL". The latter uses a DB table as storage, >> which allows extracting the references with "traditional SQL", and >> only uses the custom field for display. > > Oh, I see. I've actually never used the MasterTicketsPlugin and in > fact am rather unfamiliar with most of the available plugins. > >> I'll have to let him comment himself as to why the first approach >> was so bad, as I don't know for sure. But in both cases, there is >> additional code that manages (and enforces) the dependencies. What I >> find appealing with your approach is that it uses convention instead >> of enforcement to achieve the same effect, and with #1791, it would >> even allow the references to be real links, provided you put the >> references into a custom field. >> >> -- Remy > > I like that phrase, "convention instead of enforcement." I bet I'll > use that again somewhere soon. :) > > ticket:1791 looks interesting. On a related note, I found the > AutoQueryPlugin recently, which looks similar. Do you (or does anyone > else) know if this plugin would do what you describe here, i.e., > actually linkifying the subticket keywords thanks to their TracLinks > convention? > > http://trac-hacks.org/wiki/AutoQueryPlugin > > I might have a play with it sometime in the near future to find out if > it does. > > Personally, I think it makes more sense to keep such subticket > references in the keywords field instead of a custom field as the > whole notion is conceptually a keyword (and nothing more). It's only > through an individual project's conventions that the notion of a > "subticket" keyword actually makes any sense. For instance, it's > conceivable that keywords that begin with an octothorp mean something > entirely different to some problem domains. However, for the same > reasons, I can also see how others might consider this approach > "overloading the keywords field" and would want a custom text field > specifically for this use.
Okay, so the reason this doesn't work is as follows: The 0.10 version of mastertickets worked exactly as you describe, it used a field (a custom field but it could have just as well been the keywords) that contained the blocking/parent side of the dependency data, and then created the other side on the fly by using some SQL to extract data from the field (SELECT .... WHERE field LIKE "#n %" OR field LIKE "% #n" OR field LIKE "% #n %" etc). There are a number of problems with this approach. One, it is slower and increases DB load a good bit. Two, because the "blocked by"/child field doesn't actually exist and is generated at render time, it can't be used like a normal Trac field. It can't be changed directly (you have to click through and change it on the other side), it can't be searched, it doesn't record changes, etc etc. Basically the entire Trac system has no support for that kind of virtual field. Three, because there is no easy source of raw dependency data in a relational format, making thing like a depgraph or blocker check were much harder. You are welcome to keep going and I am sure you will discover all of these issues. --Noah PS: I still think contains-word is a good addition to the query system, I just wouldn't use it to build subtickets.
signature.asc
Description: OpenPGP digital signature
