Opened 17 years ago
Closed 4 years ago
#235 closed enhancement (wontfix)
store the sort specification in the option map instead of separate variables
| Reported by: | tv+xapian.org | Owned by: | Olly Betts |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.4.x |
| Component: | Omega | Version: | SVN trunk |
| Severity: | minor | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Operating System: | All |
Description (last modified by )
Hi,
the patch at http://people.debian.org/~tviehmann/list-search/xapian_omega_make_sortstuff_options.diff moves the sort specification into the option map and removes the sort_* variables in omega.h. This makes the sort specification better accessible from omegascript. Quite possibly, it could be improved by doing the same to docid_order.
The goal immediately at hand is to reduce the amount of changes to omega in the gmane/Debian list search patches, here to move the sort handling into the query templates.
Kind regards
Thomas
URL: http://people.debian.org/~tviehmann/list-search/xapian_omega_make_sortstuff_options.diff
Attachments (1)
Change History (13)
by , 17 years ago
| Attachment: | xapian_omega_make_sortstuff_options.diff added |
|---|
comment:1 by , 17 years ago
| op_sys: | Linux → All |
|---|---|
| Owner: | changed from to |
| rep_platform: | PC → All |
comment:2 by , 17 years ago
| Status: | new → assigned |
|---|
comment:3 by , 17 years ago
| Operating System: | → All |
|---|---|
| Summary: | store the sort specifation in the option map instead of seperate variables → store the sort specification in the option map instead of separate variables |
Yes, I think docid_order should be too.
comment:5 by , 17 years ago
| Description: | modified (diff) |
|---|---|
| Milestone: | → 1.1.0 |
Thomas: Would you mind updating this to do the same with docid_order?
comment:6 by , 16 years ago
| Milestone: | 1.1.0 → 1.1.1 |
|---|
This isn't an incompatible change, so bumping to 1.1.1.
comment:7 by , 16 years ago
I've just been looking at applying this.
I hadn't thought about this before, but this is a bit problematic if we expect these to be usefully modifiable from the template (which I assume is the point), the interaction between CGI variables and $set{OPT,VALUE} isn't very helpful, and I'm not sure how to avoid
this. If they aren't modifiable, it might be better to add new OmegaScript commands as that's
how similar cases are currently handled. Or we could add read-only options perhaps.
Are the patches for the Debian list search available anywhere? I couldn't see a link on the Debian list search page.
I can see that providing more control here would be nice, but a concrete example would help me think about this.
comment:8 by , 16 years ago
| Milestone: | 1.1.1 → 1.1.3 |
|---|
comment:10 by , 15 years ago
I do not have access to the current Debian list search templates, sorry. Given that the rationale is a bit dubious, maybe closing this until someone needs it again is the best idea. I don't think I can do this myself, though.
comment:11 by , 12 years ago
| Milestone: | 1.2.x → 1.3.x |
|---|
comment:12 by , 9 years ago
| Milestone: | 1.3.x → 1.4.x |
|---|
I think it's worth keeping this open as a placeholder, but it's not a blocker for 1.4.0.
comment:13 by , 4 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | assigned → closed |
I've since become involved in maintaining the Debian search list search, and it's been using the packaged version of Omega for several years so I think whatever the motivation for this was is no longer relevant there. We also don't have a plan for how to implement this in a useful way, so I think it's probably best to close.
patch as described