oqgraph-dev team mailing list archive

[Andrew McDonnell <bugs@xxxxxxxxxxxxxxxxxxx>]

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.

(excuse the requoting, trying to get references in one place):

>> You can't leave columns out as they're part of the schema. You can't half a
row in an RDBMS.

Yes, of course! Not sure what I was getting at there...

>>>> 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 ''

>>>> 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.

>> 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...

--Andrew



On 15/06/13 15:00, Andrew McDonnell wrote:
> Hi Arjen,
> 
> Hopefully I'll be able to tie up some of these loose ends this week, work
> permitting
> 
> --Andrew
> 
> 
> 
> 
> On 03/06/13 08:50, Arjen Lentz wrote:
>> Hi Andrew
>>
>>> The current behaviour always returns an empty set if the latch is NULL
>>> should this be changed then?
>>
>> 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.
>>
>>
>>> No latch specified seems to work correctly as you specify:
>>> - or should it not have the latch, seq, linkid columns?
>>
>> The below looks ok. Please ensure there are tests for each permutation in the basic test.
>> Perhaps we should create a no-search test as the basic test already checks schema foo which is really basic.
>>
>> You can't leave columns out as they're part of the schema. You can't half a row in an RDBMS.
>> Resultsets should always be relationally consistent - the server core will actually enforce this because as you know it always applies its own filters even if the engine doesn't.
>>
>> 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.
>>
>>
>>> SELECT * FROM graph;
>>> latch origid destid weight seq linkid
>>> NULL 1 2 1 NULL NULL
>>> NULL 2 1 1 NULL NULL
>>> NULL 1 3 1 NULL NULL
>>> NULL 3 1 1 NULL NULL
>>> NULL 3 4 1 NULL NULL
>>> NULL 4 3 1 NULL NULL
>>> NULL 5 6 1 NULL NULL
>>> NULL 6 5 1 NULL NULL
>>>
>>> Same for no latch with a filter:
>>>
>>> SELECT * FROM graph WHERE destid=2 and origid=1;
>>> latch origid destid weight seq linkid
>>> NULL 1 2 1 NULL NULL
>>>
>>>
>>>
>>>
>>> On 29/05/13 08:08, Arjen Lentz wrote:
>>>> Hi Andrew
>>>>
>>>>> what should a no_search latch return?
>>>>
>>>> For latch=0/no_search, the table should look as inserted (i.e. like
>>>> a regular table).
>>>>
>>>> I was just wondering if you'd also set "no_search" as the default,
>>>> 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
>>>> elsewhere?
>>>>
>>>>
>>> <snipped>
>>>
>>> --
>>> Mailing list: https://launchpad.net/~oqgraph-dev
>>> Post to : oqgraph-dev@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~oqgraph-dev
>>> More help : https://help.launchpad.net/ListHelp
>>
> 
>