← Back to team overview

oqgraph-dev team mailing list archive

Re: Expected result of a 'no_search' operation?

 

Hi Andrew

> Hi Arjen, just trying to mop some of this up finally.
> 
> I have split all the tests for NULL/0 and bogus values into a separate
> boundary_conditions.test so that basic.test just deals with 'routine'
> operations. I have started adding various permutations as well.

excellent


> >>>> but I reckon it might be better to use an empty string or NULL
> >>>> rather than no_search. Can you change that without causing
> >>>> hassles
> 
> I will change 'no_search to ''

How do you detect when latch is not specified at all... I think the server then just reads the raw table rather than talking through the index access method.


> >>>> For latch=0/no_search, the table should look as inserted (i.e.
> >>>> like a regular table).
> >> v2 allowed latch to be NULL, so we should probably keep that.
> >> I don't see any reason to handle NULL and 0 differently though.
> 
> 0 and NULL both return an empty result set, although for different
> reasons - 0
> is an integer subject to autocast which is not handled, and NULL is
> NULL.

Hmm - I think the result should be as above (full table) which is then filtered by the server?
What do you think?

When you do SELECT * FROM graphtable;
what does the latch column show up as?

If it's 0, then if you put in 0 you should really get back the full table.
If it's NULL, then if you put in NULL you should really get back the full table.

Either way other cols will get filtered by the server, so technically I think that returning the full table for both these cases is safe.


> >> They are NULL because there is no WHERE clause on them specifying a
> different value, and no data to return - thus it should be the default
> of the column, which in case of a NULL column (e.g. a col that can be
> NULL) with no other DEFAULT value specified in the schema, is NULL.
> 
> It is posible to specify DEFAULT on OQGRAPH engine tables?
> I might go try this out...

You can I'd think but it'd only be relevant for INSERT operations.
And since the latch column doesn't actually exist (it's not stored), yes you could DEFAULT it to whatever it reports back for the whole table, but there's not much point to it.

Not relevant for SELECT and other statements.
What's the purpose?


Regards,
Arjen.
-- 
Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
Australian peace of mind for your MySQL/MariaDB infrastructure.

Follow us at http://openquery.com/blog/ & http://twitter.com/openquery



References