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