Fred van den Driessche

re-modelling atlas

Just last week I wrote about some of the ongoing work and proposals we have to make Atlas easier to contribute to and easier to use. Part of the plan is to simplify creating adapters so you can get your own metadata into Atlas. To write to Atlas’ data stores adapters need to transform source data into Atlas’ own internal data model so it follows that the model must be understandable and easy to use. I thought I’d expand a little on the model-specific changes that are underway and give a quick preview of what to expect.

The core of the model has always focused on programmatic audio-visual data representing episodic or one-off content, films or the brand and series containers used to organise them. Along with other aspects of Atlas, the data model has grown considerably over the past year, we’ve added:

  • Topics – describing the things that a programme or segment is about.

  • Segments – sub-divisions of a programme.

  • Related Links and Key Phrases – to track hashtags and other resources connected to a programme.

  • Products – representing physical media related to a programme.

  • Channel Groups – for packaging channels together.

  • Songs – the first steps towards modelling music in Atlas.

After this quick growth we’ve taken a minute to review the model and improve consistency across all its component types. This is important because all data should be created, read and manipulated in standard ways – there should be no surprises.

As part of this drive towards consistency we’ve also taken fairly major step by making the model totally immutable – to create or modify a model type you have to go via its corresponding Builder type. The Builder pattern (see Item 2 of Josh Bloch’s Effective Java) provides a common way to configure and create immutable model instances. Let’s take a look at how you might create a Film in the new model:

Film film = Film.builder()
    .withId(1234L)
    .withSourceUri(sourceUri)
    .withSource(source)
    .withDescription(Description.builder()
        .withTitle(filmTitle)
        .withImage(imageUri)
    ).build();

As you can see, it’s very simple. The type hierarchy of the Builders mirrors the hierarchy of the main model so you can set properties of any super-class of the type in creation.

After the ‘build’ method is called the model can’t be changed. If you do need to change something simply call the ‘copy’ method. The call to ‘copy’ works its way up the type hierarchy copying the existing fields into an entirely new Builder instance:

// same as 'film' apart from the source URI
Film anotherFilm = film.copy().withSourceUri(anotherUri).build();

Builders can also be kept around partially configured – each call to build creates an new Film instance.

Hopefully this has given you a taste of what’s to come in the future in terms of Atlas’ model. It’s still at a very early stage and there’s a lot to be ironed out so the end result may be very different – as more and more of our existing remote site adapters move across to it we’ll get a better idea of how the new model fits as a language for data creation. If you have any ideas, comments or contributions please get in touch on the mailing list or github.

blog comments powered by Disqus