oqgraph-dev team mailing list archive
-
oqgraph-dev team
-
Mailing list archive
-
Message #00300
Idea for oqgraph internal architecture
Hiya
currently we have limitations: no views, only works with
innodb/aria/myisam/xtradb etc
I was looking through some of the other storage engines to get a better idea
of how things work, with the goal of fixing the memory problem. I think I am
close, we need to just use the proper memory share arrangement and possibly a
hash of tables we already opened, or something. Anwyay.
One thing I (re)realised, looking at ha_connect, is that conceptually oqgraph
could work with anything at all that has table semantics, given the right
interface.
So in theory, we could restructure oqgraph to work like ha_connect and I think
federatedx, which resolve to using the mysql client API to talk to the database.
If I was able to modify oqgraph to access the backing store like that instead
of directly hammering the raw mysql internals, it means we could work with
anything. Which means you could even chain it to ha_connect and access data in
other databases like postgres or god forbid SQL Server!
The big open question, is whether there would be any significant performance
hit using the mysql client library to access data on the same host?
just a thought bubble
--Andrew
Follow ups