Functions in data structures

[Joachim Durchholz]

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 
>>hassles anyway.)
> 
> 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 :-)

Regards,
Jo