Xapian devel - Feb 2005 - mutable Query objects

There's a bit of an API glitch with Query objects at present.  This code
shows it off:

	Xapian::Database("/path/to/db");
	Xapian::Enquire enquire(db);

	// make a simple query
	Xapian::Query myquery(Xapian::Query::OP_NEAR, phrase, phrase + 2);
	enquire.set_query(myquery);

	// Now change the query - this shouldn't affect the query enquire
	// will run, but it does.
	myquery.set_window(10);

The essential issue here is that queries are mutable, so
Enquire::set_query() needs to clone the Query object to stop it being
changed behind the scenes.

I can see two fixes for this:

(a) implement a "deep copy" clone for Query objects and use it in
Enquire::set_query()

(b) make Query object immutable by replacing these non-const public
methods with extra constructor parameters:

        void set_window(Xapian::termpos window);
	void set_cutoff(Xapian::weight cutoff);
	void set_elite_set_size(Xapian::termcount size);
	Xapian::termcount set_length(Xapian::termcount qlen);

The private non-const methods are only used during construction, so
they're not a problem.

I tend to favour (b).  The first three are tied to particular OPs
(OP_NEAR/OP_PHRASE, OP_WEIGHT_CUTOFF, and OP_ELITE_SET respectively)
so are perhaps cleaner that way anyway.  The last is more awkward
as a constructor parameter - it would perhaps be better replaced by
an optional parameter to Enquire::set_query().

This is an API change (unlike (a)), but not one which is hard to
update user code for.

I don't have strong objections to (a) - it just seems like overkill
in terms of the amount of coding work required.  But if anyone wants to
volunteer to do that work, you're welcome to...

Cheers,
    Olly

On Thu, 2005-02-24 at 16:54 +0000, Olly Betts wrote:
> (a) implement a "deep copy" clone for Query objects and use it in
> Enquire::set_query()
> 
> (b) make Query object immutable by replacing these non-const public
> methods with extra constructor parameters:
I'd favour (b) too.  The query objects aren't usefully mutable, anyway
(I can't think of a situation where it would be useful to take advantage
of them being mutable), so it would be a waste of coding and testing
time to implement a deep copy operation.  Also, it would mean that a
deep copy had to be performed every time a query is set, which currently
doesn't need to happen, so it will slow down the common case.

-- 
Richard Boulton <richard at tartarus.org>

On Thu, Feb 24, 2005 at 04:54:51PM +0000, Olly Betts
wrote:
> 	void set_cutoff(Xapian::weight cutoff);
I notice that you can also set a weight cutoff directly to Enquire (as
well as a percentage cutoff).

Is OP_WEIGHT_CUTOFF actually useful for anything?

The only potential use I can see is to implement "search within
results"
while supporting a percentage cut-off in the original query - you could
calculate the weight corresponding to that percentage once you'd run the
first query, then put that as an OP_WEIGHT_CUTOFF filter in front of the
original query before combining this with the new query.

But that wouldn't actually work though, as the querysize (and
potentially some wqfs) would be wrong for the original query once part
of the new query.

Cheers,
    Olly