well, another doubts that i had some time ago reading unireg source... 1)why it have a 64k limit? that's a logical limit (a limit in int variable or char or something like it)? or just a "well i think 64k is a good 'constant' limit"? 2)why we "still" with this "old" unireg format? i know that someone must start the new format and it will not be compatible with mysql... but there's any raw idea or a issue in mdev or lauchpad about changing .frm format or creating a new one? maybe something more human readable YAML or JSON, and a space for engine information https://mariadb.atlassian.net/browse/MDEV-3936

Roberto Spadim writes:

well, another doubts that i had some time ago reading unireg source...

1)why it have a 64k limit? that's a logical limit (a limit in int variable or char or something like it)? or just a "well i think 64k is a good 'constant' limit"?

2^16 is why there's that limit.

2)why we "still" with this "old" unireg format? i know that someone must start the new format and it will not be compatible with mysql... but there's any raw idea or a issue in mdev or lauchpad about changing .frm format or creating a new one?

maybe something more human readable YAML or JSON, and a space for engine information https://mariadb.atlassian.net/browse/MDEV-3936

See my other post: Drizzle has a protobuf based format. It's non trivial to make the server behave with this though. It appears there's some code in MariaDB to construct server data structures from a SQL statement though, so perhaps that's more usable. -- Stewart Smith

Roberto Spadim writes:

ok but why 2^16? it's based in some structure with a variable type that can't handler > 2^16 bytes? or just a number like 65555 65554 65553... ?

uses 16 bits to represent it. It's just the way it is.. hysterical raisins we used to call it.

humm i read something about protobuf, but is it human readable?

You can outptu it as human readable fairly easily, it's otherwise a compact binary format that's generally much quicker to parse than human readable. k -- Stewart Smith

hi sergei, well i start thinking about the frm file after i had a crash in my server and a aria table was read as a connect table, i removed the .frm and put another one in place, and i get my data back if i had a human readable file, that could be easier to understand but what mariadb guys think about standards? stewart talked about protobuf (i really like this idea, but don't know how to use), what about json and yaml? i think that the main problem is parse time, maybe a jornaling in this file to avoid crash? and easy implement new features, example in json we can add a new item in object just put ", 'new item':'some value'", i don

hum... i saw now the view .frm file it's nice... i don't read the internal source code, but is it easy to extend? don't have a limit like today .frm file?

Roberto Spadim writes:

hi sergei, well i start thinking about the frm file after i had a crash in my server and a aria table was read as a connect table, i removed the .frm and put another one in place, and i get my data back if i had a human readable file, that could be easier to understand

but what mariadb guys think about standards? stewart talked about protobuf (i really like this idea, but don't know how to use), what about json and yaml? i think that the main problem is parse time, maybe a jornaling in this file to avoid crash? and easy implement new features, example in json we can add a new item in object just put ", 'new item':'some value'", i don

Schemaless isn't necessarily a feature - protobuf has the benefit of enforcing a schema (XML would work too... parsing time was a concern when I wrote the code for Drizzle) -- Stewart Smith

2013/7/10 Jean Weisbuch

Hi,

Maybe a transitional setting that would create/update both the "legacy" frm file and a file with the new format when required could be a solution for backward compatibility. In that case, it would read the new format definition file if present.

Another possibility could be that we could choose the default format and only newly created tables would use that format but it wouldnt modify the existing ones (or maybe via an ALTER).

i like the ALTER idea, something like ALTER TABLE xxxx FRM_FORMAT='OLD/JSON/YAML/TEXT/xyz/protobuff/.... etc'

It also could be of use to have a tool that could offline convert the files between the two format in case MariaDB would have to be downgraded or replaced by MySQL or another fork that does not support the new definition file format.

it's nice too, i put a MDEV when my frm file crashed, maybe we could put this idea there: https://mariadb.atlassian.net/browse/MDEV-4637 ----- what format we should use? what format is easy to develop, fast, compact, human compatible, etc...? json,yaml,protobuf,text file like view format? any idea? i think that at least file should have a hash (md5 for example) to easly find crashed files, should be easly readable by humans (json/yaml/view like) and fast to read/write (protobuf for example or some binary format) i was thinking about something like (json example): "{some json definition}\n BINARY FORMAT\n MD5SUM" the MD5SUM is a MD5 value from "{" to end of BINARY FORMAT (before "\n") if we remove the BINARY FORMAT, MD5 will change, if we don't have the BINARY FORMAT mariadb read the json, and save the binary format if BINARY FORMAT exists we should use it, if some user changed the json it should remove binary format and md5 or mysql should report a error "No MD5SUM on frm file %s", "Wrong MD5SUM on frm file %s", when file don't have a BINARY_FORMAT we could log it as a warning "No binary format at frm file %s, creating..." I think it's a easy format to change (add coments) and repair file via "vi","nano","notepad" etc, i don't know how easy it's to implement at source code (json + protobuf/binary format + logs) what you think guys?

Jean Weisbuch writes:

Maybe a transitional setting that would create/update both the "legacy" frm file and a file with the new format when required could be a solution for backward compatibility. In that case, it would read the new format definition file if present.

For about the 6 months of development of the protobuf based format in Drizzle this is what I did, with a healthy number of asserts() comparing the results of reading both. For MariaDB, it would mean that when you were doing this you had two things that could break and when you finally stopped the legacy format, that would be a very clear break in any on-disk compatibility with MySQL. -- Stewart Smith

Roberto Spadim writes:

humm interesting, does mariadb have the same bugs of mysql? or it's updated like drizzle?

Same limitations as MySQL due to FRM file format. -- Stewart Smith