OQGraph v3 tables have fixed structure, the manual says
The CREATE statement must match the format below - any difference will result in an error.
It would be much more user friendly to support assisted discovery and not force the user to specify the table structure at all. Then a user would only need to type, say,
(it also renames oqgraph_table_option_struct, for simplicity, and removes redundant reinterpret_cast<>'s).
As you can see, assisted discovery is very straightforward.
This needs more testing. For example, with weight, and also with some required attributes missing, e.g. without data_table.
Sergei Golubchik
added a comment - andymc73 , here's a patch, attached.
(it also renames oqgraph_table_option_struct, for simplicity, and removes redundant reinterpret_cast<>'s).
As you can see, assisted discovery is very straightforward.
This needs more testing. For example, with weight, and also with some required attributes missing, e.g. without data_table.
OK, that applied cleanly against github
I had to update the test cases for Aria & MyISAM as well
I added regression_mdev5871 with test for bad combinations
Andrew McDonnell
added a comment - - edited Thanks for that Sergei
OK, that applied cleanly against github
I had to update the test cases for Aria & MyISAM as well
I added regression_mdev5871 with test for bad combinations
Against github — you mean, 10.1 branch? In that case, please create a pull request and I'll merge it.
Or do it with 10.0 on launchpad. Whatever you prefer.
Sergei Golubchik
added a comment - Against github — you mean, 10.1 branch? In that case, please create a pull request and I'll merge it.
Or do it with 10.0 on launchpad. Whatever you prefer.
Still need to backport to 10.0 in BZR but that will need to wait until I can sort out my fried branches in launchpad
Andrew McDonnell
added a comment - Pull request https://github.com/MariaDB/server/pull/2
Still need to backport to 10.0 in BZR but that will need to wait until I can sort out my fried branches in launchpad
Eh, no, sorry. If you want to push it into 10.0 on launchpad, I won't merge this pull request — because this code will be in 10.0, and then it'll be merged into 10.1 with the rest of 10.0.
If you don't want to have it in 10.0 — then I'll merge your pull request, adding this to 10.1 directly.
But as long as we continue to merge 10.0 into 10.1, the same patch shouldn't be merged both into 10.0 and 10.1 independently.
I'm happy to do either way, just say in what branch this patch should be present — 10.0 and 10.1, or only 10.1.
Sergei Golubchik
added a comment - Eh, no, sorry. If you want to push it into 10.0 on launchpad, I won't merge this pull request — because this code will be in 10.0, and then it'll be merged into 10.1 with the rest of 10.0.
If you don't want to have it in 10.0 — then I'll merge your pull request, adding this to 10.1 directly.
But as long as we continue to merge 10.0 into 10.1, the same patch shouldn't be merged both into 10.0 and 10.1 independently.
I'm happy to do either way, just say in what branch this patch should be present — 10.0 and 10.1, or only 10.1.
OK, off the top of my head I'll go with 10.1 because it is effectively a new feature.
Possibly Arjen may have a different opinion so perhaps hold off on that merge for a few days...
Andrew McDonnell
added a comment - OK, off the top of my head I'll go with 10.1 because it is effectively a new feature.
Possibly Arjen may have a different opinion so perhaps hold off on that merge for a few days...
As an aside, stepping back a bit I just now had a look at https://mariadb.com/kb/en/what-is-mariadb-100/ and https://mariadb.com/kb/en/plans-for-10x/ but it doesnt really explain what the "difference" is between 10.0 and 10.1
As for the difference — whatever features will be implemented in 10.1, they'll make the difference. Current plans are here. This search in Jira shows all tasks with the Fix-Version being 10.1, tasks with higher priority have a better chance of being implemented. As a rule of thumb you may think that all tasks with red priorities will end up and 10.1 and with green ones have a good chance of not making it. Although there are few closed (implemented) green tasks already.
Sergei Golubchik
added a comment - Okay, I'll wait.
As for the difference — whatever features will be implemented in 10.1, they'll make the difference. Current plans are here . This search in Jira shows all tasks with the Fix-Version being 10.1, tasks with higher priority have a better chance of being implemented. As a rule of thumb you may think that all tasks with red priorities will end up and 10.1 and with green ones have a good chance of not making it. Although there are few closed (implemented) green tasks already.
hi guys, could we do this with others engines that have 'fixed' columns? like SphinxSE
should i open a mdev for each one that could use assisted discovery?
roberto spadim
added a comment - - edited hi guys, could we do this with others engines that have 'fixed' columns? like SphinxSE
should i open a mdev for each one that could use assisted discovery?
rspadim, but SphinxSE doesn't really have a fixed structure, one can choose column types and column names within certain limits.
andymc73, shall I merge your pull request into 10.1? Meaning, it won't be in 10.0.
Sergei Golubchik
added a comment - rspadim , but SphinxSE doesn't really have a fixed structure, one can choose column types and column names within certain limits.
andymc73 , shall I merge your pull request into 10.1? Meaning, it won't be in 10.0.
Task
Major
Appears like an excellent idea, Serg.
Andrew, I've assigned this issue to you - can you have a look at it?
tnx