in scripts/mysql/my_create.sql there is no version table. does it mean that s ser database tables don't have any version number? if so, they have to be added in order to allow easy db table upgrade.
-- juha
Juha Heinanen wrote:
in scripts/mysql/my_create.sql there is no version table. does it mean that s ser database tables don't have any version number? if so, they have to be added in order to allow easy db table upgrade.
What? Why? One of the Great Annoyances of S[E]R is the feckin' versions table. We had various surprise breakages with assorted panic because of it.
Regards, Martin
Martin Hoffmann wrote:
Juha Heinanen wrote:
in scripts/mysql/my_create.sql there is no version table. does it mean that s ser database tables don't have any version number? if so, they have to be added in order to allow easy db table upgrade.
What? Why? One of the Great Annoyances of S[E]R is the feckin' versions table. We had various surprise breakages with assorted panic because of it.
Agreed -- it is definitely an unwelcome concept that causes much irritation.
Martin Hoffmann writes:
in scripts/mysql/my_create.sql there is no version table. does it mean that s ser database tables don't have any version number? if so, they have to be added in order to allow easy db table upgrade.
What? Why? One of the Great Annoyances of S[E]R is the feckin' versions table. We had various surprise breakages with assorted panic because of it.
as i already mentioned, table upgrades are much simpler if you know the current version of the table. if you don't, then your (php or whatever) upgrade script needs to analyze each field of the table based on (in case of mysql) textual output of describe statements, which is not very convenient.
if you have an easier means to do the table upgrades, please let me know. in the meanwhile, i can use my private version table.
-- juha
Juha Heinanen wrote:
Martin Hoffmann writes:
in scripts/mysql/my_create.sql there is no version table. does it mean that s ser database tables don't have any version number? if so, they have to be added in order to allow easy db table upgrade.
What? Why? One of the Great Annoyances of S[E]R is the feckin' versions table. We had various surprise breakages with assorted panic because of it.
as i already mentioned, table upgrades are much simpler if you know the current version of the table. if you don't, then your (php or whatever) upgrade script needs to analyze each field of the table based on (in case of mysql) textual output of describe statements, which is not very convenient.
if you have an easier means to do the table upgrades, please let me know. in the meanwhile, i can use my private version table.
Most database APIs provide a way to expose the table definition as well, i.e. a list of column types and names.
Juha Heinanen wrote:
Alex Balashov writes:
Most database APIs provide a way to expose the table definition as well, i.e. a list of column types and names.
that is what mysql describe and show statements do, but analyzing the output is not convenient (columns, types, attributes, index).
No, what I meant is that the database interaction library itself (e.g. libmysqlclient) provide ways to get this information into native data primitives generically, which lends itself to more generic and simple machine processing.
In the case of PHP, to run with your example, it would be something like this:
http://us.php.net/manual/en/function.mysql-fetch-field.php
This PHP function exposes a native underlying function in libmysqlclient that is sure to be accessible from the C API as well. It does not simply parse the textual output of a DESCRIBE command.
No matter how compelling this direction, it is certainly more difficult than simply using 'version' numbers -- of that there is no question.
Alex Balashov writes:
No matter how compelling this direction, it is certainly more difficult than simply using 'version' numbers -- of that there is no question.
i already made my own decision on this, i.e., i keep a private version number.
currently k db table generation from db schema as well as all k modules that use db tables assume that each table has a version.
i may get confusing if some modules in common modules dir use table versions and some do not.
-- juha
Juha Heinanen wrote:
Martin Hoffmann writes:
in scripts/mysql/my_create.sql there is no version table. does it mean that s ser database tables don't have any version number? if so, they have to be added in order to allow easy db table upgrade.
What? Why? One of the Great Annoyances of S[E]R is the feckin' versions table. We had various surprise breakages with assorted panic because of it.
as i already mentioned, table upgrades are much simpler if you know the current version of the table. if you don't, then your (php or whatever) upgrade script needs to analyze each field of the table based on (in case of mysql) textual output of describe statements, which is not very convenient.
I don't quite follow. Shouldn't it be good enough if your administrator knows these things and acts accordingly? More often than not you will have some integration with some back-office system and there will be a complex dance on every upgrade, anyhow.
if you have an easier means to do the table upgrades, please let me know. in the meanwhile, i can use my private version table.
Naturally, you can use as many tables on the side as you want. What bugs me is that S[E]R insists on reading the versions and quietly (well, sort of. The -c option doesn't catch this and you only find out when it doesn't come up after the restart command. At which point the clock is ticking) dies.
Regards, Martin
Martin Hoffmann writes:
I don't quite follow. Shouldn't it be good enough if your administrator knows these things and acts accordingly? More often than not you will have some integration with some back-office system and there will be a complex dance on every upgrade, anyhow.
i don't know about that, but for each upgrade to next version, i have an upgrade script that upgrades all db tables.
Naturally, you can use as many tables on the side as you want. What bugs me is that S[E]R insists on reading the versions and quietly (well, sort of. The -c option doesn't catch this and you only find out when it doesn't come up after the restart command. At which point the clock is ticking) dies.
i would be very easy to call a db version checking script together with -c option check in the init file.
-- juha
-
Alex Balashov -
jh＠tutpro.com -
Martin Hoffmann