Toby Corkindale wrote:
> Sadly, I'm stuck on the abhorrent-in-the-eyes-of-all
4.0.xx versions;
> I want to try and remove obstacles to upgrading one day
when the
> higher powers allow though, and so using TIMESTAMP is
ruled out as
> its behaviour and format changes between almost every
version of
> 3/4.0/4.1/5.0/etc! I wish they'd fixed the DATETIME
DEFAULT issue in
> 5.0 actually, as it might have been a help to push
towards upgrading
> to it.
Toby, I recommend you to seriously consider using strings or
integers
(depending on your range and precision needs) to hold dates,
and relay
on converting them to proper date types at the application
side.
MySQL DATETIME ranges are minimalistic and doesn't allow
much more than
conventional commercial applications. Even some
complementary retirement
funds have problems managing data without using out-of-bound
dates.
I believe that this can be properly addressed into
DateTime::Format::MySQL, by specializing the class to
convert {from,to}
{strings,integers} instead of the conventional DATETIME data
type.
[REPLACE INTO 'feature']
> It's like they realised that they didn't have decent
transaction
> support, so made an atomic delete/insert method
instead. And then
> poor fools used MySQL, and used these non-standard
commands as the
> only way to do things, and then poor fools like me came
along and had
> to support it later.
I agree, it doesn't sounds sensible. I hope that being part
of the Sun
world help changing this (I hope that Sun plans their
software better
than MySQL does).
I would rather put the database in STRICT MODE, and never
ever allow
people to use that. If they already used it, arrange a test
for the
system and set removing this kind of code as a short-term
goal for the
maintenance team.
My twoppence.
--
Luis Motta Campos (a.k.a. Monsieur Champs) is a software
engineer,
Perl fanatic evangelist, and amateur {cook, photographer}
|
