Hi Brian,
On Nov 19, 2009, at 11:27 AM, Brian Aker wrote:
Hi!
On Nov 19, 2009, at 1:36 AM, Paul McCullagh wrote:
Engines that have a different record format to Drizzle can loop
through the Field objects. And engines that do not require there
own storage format, can write out the bytes straight from the buffer.
MySQL has changed its in memory representation of types a couple of
times now, what are you planning on doing when that happens?
Yes, this is quite a problem if this happens.
Basically I will have to provide a conversion routine from the old
format to the new. The conversion will have to occur, on the fly, when
a record is written or read.
Or I could insist that a REPAIR TABLE be done in order to "upgrade" to
the new format. Then I would only have to provide a conversion
function from the old format to the new.
I think MyISAM would have the same problem so I hope this will
discourage MySQL from doing this in the future! :)
It may make sense to leave BLOB data out of the record buffer, but
maybe not as MySQL does it today, with a pointer to the BLOB data
in the buffer. The reason is because this messes things up. A
buffer with pointer in it cannot be copied as is to disk.
Good point, I hadn't actually thought about this particular bit.
So the Field object could reference a different block of memory for
each BLOB. The engine can then just write the BLOBs in order, after
the main record, if it stores the data consecutively on disk.
That is pretty viable.
Are you sure you don't want to find a way to store the majority of
types in some native fashion? I would think you would want to be
able to safely check the data no matter the version of the database.
A lot of types: INT, FLOAT, STRINGs, BLOBs, have a format that will
probably never change. The types that are most likely to change are
DATE, TIME and DECIMAL values.
If I provide my own format for these then I also have to provide my
own comparison routines, which need to by 100% compatible with the
routines used by the server.
In addition, I don't really think I can create formats and routines
that are significantly better than the routines that already exist in
MySQL.
And, if I use my own format, and the internal format changes, then I
have the work of changing my conversion routines anyway.
So not already having my own super-cool data types (unlike an engine
such as Falcon) this lead to my decision to use the MySQL formats and
comparison functions.
Either way, this really means that we should give DATE, TIME and
DECIMAL formats in Drizzle some thought (which has been done for
DECIMAL), and get it right from the very start. :)
Best regards,
Paul
--
Paul McCullagh
PrimeBase Technologies
www.primebase.org
www.blobstreaming.org
pbxt.blogspot.com
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
