2 Jul
2009
2 Jul
'09
5:46 p.m.
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
6 Jul
6 Jul
9:55 a.m.
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
10:05 a.m.
Martin Hoffmann wrote:
Juha Heinanen wrote:
Agreed -- it is definitely an unwelcome concept that causes much irritation.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
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.
10:10 a.m.
Martin Hoffmann writes:
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
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.
10:17 a.m.
Juha Heinanen wrote:
Martin Hoffmann writes:
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.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
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.
10:39 a.m.
Juha Heinanen wrote:
Alex Balashov writes:
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
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
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).
10:42 a.m.
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
10:57 a.m.
Juha Heinanen wrote:
Martin Hoffmann writes:
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.
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. 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
11:10 a.m.
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
5629
days inactive
5633
days old
9 comments
3 participants
participants (3)
-
Alex Balashov -
jh＠tutpro.com -
Martin Hoffmann