Support inheritance for models

This needs to be supported and tested:

class Base extends Model {}
Base.init({ whatever: DataTypes.STRING }, { tableName: 'base_table' })

class Derived extends Base {}
Derived.init({ second: DataTypes.INTEGER }, { tableName: 'derived_table' })

Derived.options.__proto__ === Base.options
Derived.attributes.__proto___ === Base.attributes

Derived inherits all attributes and options from Base.

Model.init() should do something like

this.options = Object.assign(Object.create(this.options), options)

[felixfbecker]

That means that if the derivative doesn’t explicitly overwrites tableName in it’s options than options.tableName === ‘base_table’ will always be true and will be set as the model table name

All that needs to be done is default tableName to the model name. It’s really not an issue. We can check options.tableName before you seting up the new object with inheritance or use hasOwnProperty().

init in itself is not as bad. But we have a weird situation where a Model class actually creates Row instances instead of Models. Think about calling New Buffer(); and instead of getting a Buffer you’ll get a 16bit value. So effectively Sequelize doesn’t have a Model class and that is why inheritance is so messy or why your decorators doesn’t really work. It is too late to fix now but it is something we should be aware of and aim to fix when possible.

I think you are misunderstanding the “Model” term in Sequelize. Sequelize uses the Active Record pattern. The Model is the class, instances are concrete rows. This is not a mistake, it’s a design choice. After all, classes in JavaScript are just objects themselves, so there is no reason to separate them like in v3 where there was an Instance class and a Model class. It didn’t have any benefit. The Model class is abstract, it could just as well be named Entity or Row, it’s just naming. A different name doesn’t make inheritance messy or decorators not work.

How many users actually use history tables ? more than having multiple tables with ids and timestamps and other properties ? More than people having multiple servers and connections they might have to attach identical models to ?

The use case is huge. Any application that stores data of legal importance needs to keep a change history. Comparing the number of these users to the number of users needing “abstract” models for inheritance doesn’t make sense because they don’t contradict each other. With the way I suggest it, you can easily support both use cases. With your way it only supports the abstract model use case.

Any way doing inheritance properly you could use them for both history tables and other solutions, but by forcing it to be part of the init process you are basically locking it to one use case.

What’s the problem with abstract: true?

I think this is enough reason for wanting the inheritance process to be decoupled from the init. We should look at init as way to instantiating a Model object as if we actually had a class for it.

I don’t understand this paragraph, could you explain? init is a static constructor. It initialises the static side of the class. Models are classes and in JavaScript, classes are objects. Instantiating the concrete Model (e.g. User) is done by new User() and gives you a User instance/row.

[schieck0]

5 years later…