Greg Stark kirjutas K, 12.03.2003 kell 07:10:
> "Marc G. Fournier" <scrappy@hub.org> writes:
>
> > Personally ... as long as a v8.x client can talk to a v7.x backend, you
> > have my vote ... I'm more apt to upgrade my clients before my servers
> > anyway ...
>
> Surely that's not true for a production environment. You have one database but
> potentially dozens of various programs around that access it. The main
> application, some backend scripts for batch jobs, your backup process, your
> monitoring systems... Not all of these are necessarily on the same machine.
For more radical protocol changes a viable approach could be "protocol
proxies", i.e. set up a _separate_ daemon which listens on a separate
port and translates v7.x wire protocol to v8.x of the database proper.
Then those needing it can keep it around and those who need it not don't
get the overhead. It could also be maintained by inerested parties long
after being dropped by core developers.
> It's upgrading the database that's likely to be the driving motivation for new
> sql or storage features. People usually don't get excited about upgrading the
> client libraries :)
But our SQL itself is slowly drifting towards ANSI/ISO compliance and
that has often brought subtle changes that break _applications_. It is
not a big issue to changes libraries if you have to change the
application anyway.
-----------------
Hannu
