Opened 11 years ago
Closed 21 months ago
#638 closed enhancement (fixed)
Use front coding for termnames when serialising stats?
| Reported by: | Olly Betts | Owned by: | Olly Betts |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.5.0 |
| Component: | Backend-Remote | Version: | git master |
| Severity: | normal | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Operating System: | All |
Description
serialise_stats() doesn't currently use front coding for the query terms. For short queries, this won't help, but for large queries it could. Partly it depends how we end up handling wildcards once I've finished implementing delayed expansion - if the expanded terms all still go in the termfreqs, then this would help that case a lot.
Change History (4)
comment:1 by , 9 years ago
| Milestone: | 1.3.x → 1.4.x |
|---|
comment:2 by , 5 years ago
| Milestone: | 1.4.x → 1.5.0 |
|---|---|
| Type: | defect → enhancement |
| Version: | SVN trunk → git master |
Marking to at least consider for 1.5.0.
comment:3 by , 21 months ago
| Status: | new → assigned |
|---|
Partly it depends how we end up handling wildcards once I've finished implementing delayed expansion - if the expanded terms all still go in the termfreqs, then this would help that case a lot.
We do send termfreqs for terms expanded from OP_WILDCARD.
comment:4 by , 21 months ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Implemented for git master in [0303ab022a9ff3f077b1f7f3bc544582a152e542]. Changes the remote protocol so not suitable for 1.4.x.
Not a blocker for 1.4.0 - we could add this with a minor protocol bump (server adds new message+response for this but continues to support the old message+response; new clients send the new message and get the new response, while old clients send the old message and get the old response).