Functions in data structures
Wed Jun 18 15:15:05 CEST 2003
Wiger Ulf wrote:
> From: "Joachim Durchholz" <joachim.durchholz@REDACTED>
>>Anyway, I have decided to send just plain data, no functions. Code will
>>be sent in the form of software upgrades, just the way that people
>>expect things to work. (Sending functions implies all sorts of security
> You may want to include a version indicator in the messages going
> between nodes. There are currently a few things that can mess up
> certain code upgrades:
> - record structures are compile-time dependent
> - mnesia can not have multiple simultaneous versions of the schema
> Thus, if you send records in messages between nodes, and have a
> fully distributed database, it is a bit more difficult to upgrade code
> one node at a time (an otherwise attractive option).
Fortunately, it's unlikely that full records will ever be sent directly.
The general structure will be as follows:
One server, distributed over several physical machines. Distribution is
both for scalability and redundancy; there is no communication between
server machines except Mnesia replication and some load-balancing
protocol. The server is intended to run 24/7.
Lots of clients, each sitting on one physical machine. Clients interact
just with the server, not directly with each other. Clients will run for
a short period and terminate.
In this scenario, changes in the protocol between client and server are
most likely to cause problems.
Changes in the Mnesia schema on the server comes next. I've been
thinking about adding a version number to each table name, and add a
layer that retrieves and converts data from previous-version tables if
the current-version table doesn't have the data. Updates simply go to
the latest version of the table, resulting in a convert-on-the-fly
schema. (The critical point here is conversion, which must be 100%
correct - but that would have to be correct whether the conversion is
done in batch mode or on the fly.)
> The main reason for this rambling is that you need to spend some
> time rather early thinking about what your upgrade requirements are,
> and how they affect your design choices.
I hope the above doesn't contain too many thinkos :-)
More information about the erlang-questions