4

Web applications usually have a database. The code and the database work hand in hand together. Therefore Frameworks like Ruby on Rails and Django create migration files

Sure there are also servers written in Self or Smalltalk or other image-based systems that face the same problem: Code is not written on the server but in a separate image of the programmer.

How do these systems deal with a changing schema, changing classes/prototypes. Which way do the migrations go?

Example: What is the process of a new attribute going from programmer's idea to the server code and all objects?

I found the Gemstone/S manual chapter 8 but it does not really talk about the process of shipping code to the server.

User
  • 795
  • 4
  • 9

2 Answers2

1

I think the migration file based method has been an innovation.

Before that new schema's were mostly created by building "converters", in other words, creating an entirely new image then copying user data in in it's new shape.

Alternatively an image can contain schema version metadata per record so a reader could migrate (and store in new format) on the fly or in a (lower priority) background process. Similar techniques you may find build on top of document databases these days.

The focus on small text based migration in small delta's has been an improvement over previous practices though.

Joppe
  • 4,548
  • 17
  • 25
1

In Gemstone there are class versions and you can have objects of multiple class versions in the system. By default, adding a new attribute just adds it with a nil value. With a lazy accessor you can just set the value when needed. Or you can do an active migration and decide what needs to happen, either for all old objects when loading the new class definition or lazily, whenever one is used.

In Pharo we just have the default behaviour, adding an instance variable nils it. That means that loading a new version can potentially be slow, e.g. when needing to add an instVar to a million objects. If we need more than just a new property, we add migration code that runs before or after loading the new version.