[MDEV-5871] support assisted discovery in oqgraph v3 Created: 2014-03-15 Updated: 2014-12-04 Resolved: 2014-12-04 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - OQGRAPH |
| Fix Version/s: | 10.1.2 |
| Type: | Task | Priority: | Major |
| Reporter: | Sergei Golubchik | Assignee: | Sergei Golubchik |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | oqgraph | ||
| Attachments: |
|
| Description |
|
OQGraph v3 tables have fixed structure, the manual says
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,
Assisted discovery is easy, see federatedx.cc and sequence.cc for examples. |
| Comments |
| Comment by Arjen Lentz [ 2014-03-17 ] |
|
Appears like an excellent idea, Serg. |
| Comment by Sergei Golubchik [ 2014-06-20 ] |
|
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. |
| Comment by Andrew McDonnell [ 2014-06-22 ] |
|
Thanks for that Sergei OK, that applied cleanly against github |
| Comment by Sergei Golubchik [ 2014-06-22 ] |
|
Against github — you mean, 10.1 branch? In that case, please create a pull request and I'll merge it. |
| Comment by Andrew McDonnell [ 2014-06-22 ] |
|
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 |
| Comment by Andrew McDonnell [ 2014-06-22 ] |
|
heh, while I was still pushing things to github you added that comment |
| Comment by Sergei Golubchik [ 2014-06-22 ] |
|
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. |
| Comment by Andrew McDonnell [ 2014-06-22 ] |
|
OK, off the top of my head I'll go with 10.1 because it is effectively a new feature. 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 |
| Comment by Sergei Golubchik [ 2014-06-22 ] |
|
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. |
| Comment by roberto spadim [ 2014-09-20 ] |
|
hi guys, could we do this with others engines that have 'fixed' columns? like SphinxSE |
| Comment by Sergei Golubchik [ 2014-09-20 ] |
|
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. |
| Comment by Sergei Golubchik [ 2014-10-12 ] |
|
Ok, 10.1 then. |