oqgraph-dev team mailing list archive

[Andrew McDonnell <bugs@xxxxxxxxxxxxxxxxxxx>]

Hiya

got it working for breadth_first as '2' and djikstra as '1', by storing the
original string into the graph before calling search and then putting it into
the row_info. Its ugly but it works.  Later this can all probably be
refactored to be cleaner.

(1) However, it causes an assertion outside of ha_graph when you try and use
'0' for 'no_search' (see after)

(2) If you use latch = 2 instead of latch = '2' the only function I see it
call is fill_record(), it seems to skip the index checker and search() in that
case; and call fill_record() for as many rows in the backing graph.

I am probably not going to have much time over the next week, maybe a few
minutes on Sunday.

--Andrew


Assertion after

SELECT * FROM graph2 WHERE latch='0' and destid=2 and origid=1;



#0  0x00007ffff6fce1b5 in *__GI_raise (sig=<value optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff6fd0fc0 in *__GI_abort () at abort.c:92
#2  0x00007ffff6fc7301 in *__GI___assert_fail (assertion=0xecab18 "(uchar*)
table->def_read_set.bitmap + table->s->column_bitmap_size == (uchar*)
table->def_write_set.bitmap", file=<value optimized out>, line=5389,
function=0xecaf20 "int handler::ha_reset()") at assert.c:81
#3  0x00000000007eb6a9 in handler::ha_reset (this=0x29e9e58) at
/home/andrew/develop/maria/repo/oqgraph-varchar/sql/handler.cc:5387
#4  0x00000000005b1207 in close_thread_table (thd=0x7fffe81d44c0,
table_ptr=0x7fffe81d4578) at
/home/andrew/develop/maria/repo/oqgraph-varchar/sql/sql_base.cc:1648
#5  0x00000000005b09c4 in close_open_tables (thd=0x7fffe81d44c0) at
/home/andrew/develop/maria/repo/oqgraph-varchar/sql/sql_base.cc:1391
#6  0x00000000005b0f5d in close_thread_tables (thd=0x7fffe81d44c0) at
/home/andrew/develop/maria/repo/oqgraph-varchar/sql/sql_base.cc:1603
#7  0x000000000061cc6b in mysql_execute_command (thd=0x7fffe81d44c0) at
/home/andrew/develop/maria/repo/oqgraph-varchar/sql/sql_parse.cc:4904
#8  0x000000000061f9ec in mysql_parse (thd=0x7fffe81d44c0, rawbuf=0x2886dc8
"SELECT * FROM graph2 WHERE latch='0' and destid=2 and origid=1", length=62,
parser_state=0x7ffff7f63670) at
/home/andrew/develop/maria/repo/oqgraph-varchar/sql/sql_parse.cc:6124
#9  0x00000000006129ba in dispatch_command (command=COM_QUERY,
thd=0x7fffe81d44c0, packet=0x7fffe81d9761 "", packet_length=62) at
/home/andrew/develop/maria/repo/oqgraph-varchar/sql/sql_parse.cc:1266
#10 0x0000000000611b35 in do_command (thd=0x7fffe81d44c0) at
/home/andrew/develop/maria/repo/oqgraph-varchar/sql/sql_parse.cc:982
#11 0x0000000000721ba9 in do_handle_one_connection (thd_arg=0x7fffe81d44c0) at
/home/andrew/develop/maria/repo/oqgraph-varchar/sql/sql_connect.cc:1267
#12 0x0000000000721651 in handle_one_connection (arg=0x7fffe81d44c0) at
/home/andrew/develop/maria/repo/oqgraph-varchar/sql/sql_connect.cc:1181
#13 0x00007ffff7bc98ca in start_thread (arg=<value optimized out>) at
pthread_create.c:300
#14 0x00007ffff706b92d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#15 0x0000000000000000 in ?? ()



On 08/03/13 06:48, Arjen Lentz wrote:
> Good steps!
> Yes on output the cols used in where need to match otherwise the server core will filter out those rows. So that aspect is clear.
> 
> Andrew McDonnell <bugs@xxxxxxxxxxxxxxxxxxx> wrote:
> 
>> Hello all
>>
>> (Sorry this is a little muddled, I need to go to bed!)
>>
>> Using the code from basic.test I can get results with
>>
>> SELECT * FROM graph2 WHERE latch = 'breadth_first' AND origid = 1 AND weight = 1;
>>
>> that match
>>
>> SELECT * FROM graph WHERE latch = 2 AND origid = 1 AND weight = 1;
>>
>> (Here, graph2 is the same as graph but with a varchar latch)
>>
>>
>> (BTW Arjen, I completely get your point about not maintaining backwards
>> compatibility for int latch but I am finding it extremely useful to compare
>> results when testing and also understand stuff in the debugger.  So I would
>> like to leave the #ifdef code there as scaffolding until everything works and
>> then remove it)
>>
>>
>> However:
>>
>> SELECT * FROM graph2 WHERE latch = '2' AND origid = 1 AND weight
>>
>> I can see from the debug that the '2' is being parsed correctly to
>> breadth_first and then index_read_idx() executing graph->search() with exact
>> same arguments.
>> However the query returns no results, despite graph->fetch_row() apparently
>> working at.
>> I can see fill_record() is only called once (not four times as when called
>> when latch is a named string - notably, the 'breadth_first' result has
>> fill_record() called by multi_range_read_next, which I dont see happening with
>> latch='2')
>>
>> I suspect this is somehow key related: I populate the row with the string
>> 'breadth_first' but mysql is looking for a '2' on the first row returned?
>>
>> What I haven't worked out yet is how to get the original latch string from the
>> query to put into the result in fill_record(), which might fix the above.
>> It may be necessary to hack some additional state into the graph object to
>> pass this key string through.
>>
>>
>> Also, I can crash mysqld with an assertion by simply putting a bogus value in
>> for latch, but the stacktrace is not in our code, which leaves me in a bit of
>> a bind.
>>
>> Finally, if I go
>>
>> SELECT * FROM graph2 WHERE latch = 2 AND origid = 1 AND weight = 1;
>>
>> it never enters records_in_range() at all, even from a restart / cache reset
>> so it seems to be not auto casting to a string in this case.
>>
>> I suspect I may be missing something with the keys still somewhere...
>>
>>
>>
>> anyway,
>> enjoy
>>
>> (as previously noted, I wont have much time over next week)
>>
>>
>> BTW, I am using NetBeans as a glorified text editor with code completion, and
>> able to attach gdb to mysqld for graphical debugging, I can post instructions
>> later if you are interested
>>
>>
>> -- 
>>
>>
>> https://launchpad.net/~andymc73
>> http://blog.oldcomputerjunk.net
>> Twitter: @andymc73
>> GPG: http://www.andrewmcdonnell.net/gpg.html
>>
>> -- 
>> 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