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 <b...@andrewmcdonnell.net> 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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~oqgraph-dev >> More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~oqgraph-dev Post to : oqgraph-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~oqgraph-dev More help : https://help.launchpad.net/ListHelp
