Olly Betts <olly at survex.com> writes:> A better option for this is probably a FieldProcessor - you set one for > a prefix and the it gets passed the value and returns a Query object > for it. E.g. in lua (where you can just pass an anon function for the > FieldProcessor - we ought to support C++11 lambdas for such things):[snip]> To achieve this with synonyms in a configurable way you'd need to > rewrite the synonyms in the database to match the current configuration, > so it's not as dynamic as the above.Well, the configuration needs to be somewhere. Would it make sense to from a performance point of view to be looking up foo_tag_term in document metadata? That was one of the attractions of using synonyms that there is already a persistent/atomic/configurable way of storing them. With a field processor we'd have to manage that ourselves, and I'm hoping to avoid managing my own cache, at least in the first revision.> FieldProcessor isn't in 1.2.x, but then support for synonyms for boolean > terms isn't in any version.[ Debian specific discussion follows; non-Debian users might find it boring and incomrehensible ] Yeah. I guess if there were 1.3 packages in Debian (experimental?), I'd consider optionally depending on them. There are several places where field processors could be useful for notmuch. I see the packages exist in Ubuntu, so I guess there wouldn't be that much packaging work? I guess this would be a perfect application of so-called "bike sheds", but who knows when these will actually become live. Would it help anything if I filed an RFP bug? d
On Tue, Jan 05, 2016 at 08:43:13AM -0400, David Bremner wrote:> Olly Betts <olly at survex.com> writes: > > > To achieve this with synonyms in a configurable way you'd need to > > rewrite the synonyms in the database to match the current configuration, > > so it's not as dynamic as the above. > > Well, the configuration needs to be somewhere. Would it make sense to > from a performance point of view to be looking up foo_tag_term in > document metadata?Calling get_metadata() is pretty much exactly equivalent to reading the synonyms for a term - both read one Btree entry, just from different tables. Longer term, I wonder if synonyms should happen via FieldProcessor - that would neatly deal with how to do synonyms for different fields in a flexible way, and also allow synonyms to expand to phrases or even other types of subqueries.> > FieldProcessor isn't in 1.2.x, but then support for synonyms for boolean > > terms isn't in any version. > > [ Debian specific discussion follows; non-Debian users might find it > boring and incomrehensible ] > > Yeah. I guess if there were 1.3 packages in Debian (experimental?), I'd > consider optionally depending on them. There are several places where > field processors could be useful for notmuch. I see the packages exist > in Ubuntu, so I guess there wouldn't be that much packaging work?I've actually already updated the packaging for 1.3.x for one of my clients who have already switched (I've not done 1.3.4 yet, but it shouldn't be a big update). I know Ubuntu were aware of this updated packaging so I'd imagine that's what they're using, but I've not looked. It's probably about time to get 1.3.x packages into experimental. It'd also make it fairly easy to test rebuilding dependent packages to see if there are any pain points in the API changes while we still have more freedom to address them. In theory little should need changing, and it would be good if practice matched that.> I guess this would be a perfect application of so-called "bike sheds", but > who knows when these will actually become live. Would it help anything > if I filed an RFP bug?Feel free to, but realistically it probably won't make it happen sooner. Cheers, Olly
Olly Betts <olly at survex.com> writes:> On Tue, Jan 05, 2016 at 08:43:13AM -0400, David Bremner wrote: >> Olly Betts <olly at survex.com> writes: >> >> > To achieve this with synonyms in a configurable way you'd need to >> > rewrite the synonyms in the database to match the current configuration, >> > so it's not as dynamic as the above. >> >> Well, the configuration needs to be somewhere. Would it make sense to >> from a performance point of view to be looking up foo_tag_term in >> document metadata? > > Calling get_metadata() is pretty much exactly equivalent to reading the > synonyms for a term - both read one Btree entry, just from different > tables.Just this morning I realized any lookup would happen during query parsing, which seems pretty unlikely to be a bottleneck. d