Hi!
I do not know that long term we will always be doing SQL, so I am not
sure that a domain specific solution is good.
Think about blob storage plus what the CouchDB guys have been up to.
We have the same infrastructure, it is just a matter of interface.
What do I really think we need to do? Punt this to engines and let
them take a table object and inspect it/build it. Let engines handle
their own definitions.
Cheers,
-Brian
On Aug 3, 2008, at 12:08 PM, Paul McCullagh wrote:
I would vote for storage in text form as SQL.
Advantage: the same parser can be used for both table creation and
reading in the FRM information, so why code this logic twice?
Its not tamper free, but that might even be useful if you want to
tweak the schema. In general I'm for giving people more rope,
because it is obvious that fiddling with something like this is
dangerous, and if not then the warning in a comment at the beginning
of the file will tell them so :)
It may be a bit slower than a binary format, but is this critical?
(Well maybe it is if you want get rid of the table cache)
On Aug 1, 2008, at 10:50 PM, Brian Aker wrote:
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
--
_______________________________________________________
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
