Hi!
1) Engines should be asked about tables, and tables belong to engines.
2) We still need some sort of FRM for Engines which have no ability to
handle their own data dictionaries.
The current Unireg format is a real pain in the butt and has not been
scaling well with recent additions. It pre-set binary type.
Three methods for storage:
1) XML (slow)
2) SQL (tamper-able/less slow)
3) Binary Stream
Personally I am for types 2 or 3 for a serial method. In fact I am for
both being added to the table class.
For the binary type though I see a few choices:
1) Google Protocols (not in distributions, beta)
2) Science Types/ASN (also not in distributions)
3) Envelope style (you have to roll your own, but cake to do (think
ID3)).
Thoughts? Additional ones?
I lean toward #3 only because I fear the hassle factor in the above
ones (it is also simple and easy to understand). I am hoping we can
get our hands into Innodb and just use its for tables it has.
Oh, and why do engines need to know? If an engine is not available we
do not want to know about its tables, and if an engine is network
based things get a lot more complicated.
BTW for methods think:
tbl = new Table(binary/char array);
and:
char *ptr= table->serialze();
or
char *ptr= table->create_table_string();
Cheers,
-Brian
--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/ <-- Me
http://tangent.org/ <-- Software
_______________________________________________________
You can't grep a dead tree.
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
