oqgraph-dev team mailing list archive

[Andrew McDonnell <bugs@xxxxxxxxxxxxxxxxxxx>]

Hi Arjen, Antony

So I just had a quick look:

The latch is currently an integer which eventually gets translated as an
operation in graphcore.cc oqgraph::search()

Where the operation seems to be a bit set:

NO_SEARCH | HAVE_ORIG | HAVE_DEST
NO_SEARCH | HAVE_ORIG
NO_SEARCH | HAVE_DEST
NO_SEARCH

etc.

And I guess you would like to translate to a string because that will be
easier to extend in the future?

What syntax is required? (Apologies if you already discussed in passing
traffic and I missed it)


So, I have a back of the envelope plan to reduce the risk and try and meet the
merge:

1. Implement the varchar interface but make no changes to oqgraph::search().

A parser would be called in ha_oqgraph.cc just prior to calling
oqgraph::search(), translating to the bitset.  This way the interface upgrade
can integrated onto MariaDb quicker, to reduce the number of changes to be
tested, and allow the SQL-side interface to be bedded down and be merged.

2. Then at a later date, refactor search() to take a string and do the
parsing.  This could be after the upcoming merge, as it would be entirely
internal to ha_oqgraph.cc, etc

3. In the future, internally, search() could even be improved to have a kind
of lookup table and algorithm implementation class allowing easy addition of
new algorithms without changing oqgraph::search() itself when new algorithms
get added.  A kind of algorithm plugin for our storage plugin if you will!


Or I could be barking up the wrong tree ...



--Andrew