oqgraph-dev team mailing list archive

[Antony T Curtis <atcurtis@xxxxxxxxx>]

In general, this is the CREATE TABLE statement for v3:

CREATE TABLE graph (

latch SMALLINT UNSIGNED NULL,

origid BIGINT UNSIGNED NULL,

destid BIGINT UNSIGNED NULL,

weight DOUBLE NULL,

seq BIGINT UNSIGNED NULL,

linkid BIGINT UNSIGNED NULL,

KEY (latch, origid, destid) USING HASH,

KEY (latch, destid, origid) USING HASH

) ENGINE=OQGRAPH

data_table='*link*'

origid='*source*'

destid='*target*';


where "link" specifies the table containing all the links and "source" is
the name of the column containing the source node id within the "link"
table and "target" is the name of the column containing the target node id
within the "link" table.

Regards,
Antony


On 23 February 2013 22:35, Andrew McDonnell <bugs@xxxxxxxxxxxxxxxxxxx>wrote:

> Hi Arjen
>
> (see also my other longer post!)
>
> I am thinking the easiest route to start with is to change the return type
> if
> init_tmp_table_share() to int and return an error; those other callers in
> the
> system will ignore it for now as they already do
>
> ha_oqgraph::open returns an error code, so it can do so in this case.
>
>
> --Andrew
>
> On 20/02/13 10:20, Arjen Lentz wrote:
> > Hi Andrew
> >
> > I think the create table statement is incomplete for v3, as in v3 there
> is no local storage but instead the columns need to be mapped onto cols of
> an existing base table (generally InnoDB).
> > Antony, can you update us on the correct CREATE TABLE for v3?
> >
> >
> >> INSERT INTO tol_tree (origid,destid)
> >> SELECT parent,id FROM tol WHERE parent IS NOT NULL;
> >>
> >> this failed ... (stack trace attachment)
> >>
> >> I note the stack trace is full of mangled C++ identifiers ...
> >>
> >> I then ran mysqld from gdb. The fault repeated the same, but gdb let
> >> me see the identifiers. (attach #2) and of course, catch the fault and
> >> examine variables.
> >>
> >> It turns out that options->tablename in ha_oqgraph::open (-->
> >> table_name in table.cc) is NULL. And strlen barfs because table.cc
> >> isn't checking for a NULL.
> >>
> >> I am unfamiliar with the code as yet, so I don't know why this is
> >> NULL.
> >>
> >> As an aside, I am used to working with code that is defensively laced
> >> with assertions for NULL pointers, so this is a little different to
> me...
> >
> > Well that's clearly an omission and a bug in the new code.
> > Crashing a multi-threaded/multi-user daemon is not nice. So generally
> when something fails in MySQL, you have a mechanism to return a fail from
> that function.
> > At the very least you'd have an assert in there (do add it), but
> obviously you'd want to code to not get into that situation in the first
> place
> >
> >
> > Cheers,
> > Arjen.
>
>
> --
> 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
>



-- 
Antony T Curtis
0523 C487 9187 6972 6894
AEC7 3087 F819 B477 B687