[mb-users] Digest of a personal thread that Fuchs started (Was: Uff ...)

[Björn Krombholz]

On 8/20/06, Bogdan Butnaru <bogdanb at gmail.com> wrote:
> On 8/20/06, Steve Wyles <steve at inhouse.co.uk> wrote:
> > Also running a test server in tandem against the live database would be
> > very unwise.
>
> Yes, that's clearly true. But I didn't suggest running the test server
> in tandem. (At least, I wasn't trying to :))
>
> I suggested that _after_ all the testing is done on the test server,
> instead of just applying the feature to the main server, we _add_ it
> to the main server in parallel to the old one. This is no more
> dangerous, and actually safer than what we do now: after testing on
> the test server we just apply everything.
>
> With a gradual "apply" we can start using it with more and more
> people, solving issues as they are discovered, until it replaces the
> old version, at which point we remove the old system. This is the way
> Yahoo is upgrading their webmail interface.

Actually for MB this would mean running 2 servers on top of the same
database. The way Yahoo and Google do such testing by switching one
data center to a new version and randomly routing users to this data
center doesn't work with MB.

There are 2 scenarios for which this works and both apply for the kind
of projects Yahoo and Google are running.

1. Read only database access, like the search services: It doesn't
matter how many different interfaces access the database backend,
because no data is changed concurrently.

2. PIM projects: Here each user has read/write access to "his" own
parts of the database. In webmail services, you can of course only
read and write your mails only. And  the user is only running one UI
to access his data, so it doesn't matter that different users might
access their data with different client implementations, because each
user data block is independent of another user's data block.


In MB we have one central database. And to allow real testing of new
features, the new features need to be tested on the real database.
Today the test server has it's own DB, but it doesn't really make
sense for a user to do intensive testing on this server, as all the
changes are lost eventually and not propagated to the main DB.

Allowing concurrent access of both servers (or 2 implementations of a
feature) on the same DB would need a new (or improved) layer between
the UI and the DB that allows mutex access to single entries in the
DB. And this wouldn't really work when it comes to DB schema changes.


So the idea is nice, but probably a bit over engineered for MB, at
least it would need a lot of work to implement a working system that
allows such testing.


#Fuchs