Table extensions examples

[fstagni]

No description provided.

[chrisburr]

Closing this until we have a use case to consider.

[fstagni]

I do not agree with closing this one. It provides examples and a much needed documentation that I do not see anywhere else.

[chrisburr]

This PR is mixing pyproject.toml changes with DB changes and also needs to have the column modification example removed.

[read-the-docs-community]

Documentation build overview

📚 diracx | 🛠️ Build #31554151 | 📁 Comparing 0387ff6 against latest (6e85d84)

🔍 Preview build

Show files changed (1 files in total): 📝 1 modified | ➕ 0 added | ➖ 0 deleted

File	Status
dev/explanations/extensions/index.html	📝 modified

[aldbr]

Just wondering, do we even give the possibility of extending DBs by adding columns?
Is there any use case? From what I understand, only LHCb is concerned.

[fstagni]

Just wondering, do we even give the possibility of extending DBs by adding columns? Is there any use case? From what I understand, only LHCb is concerned.

It is easy enough, I do not see why not, and at least an example exists.

[chrisburr]

It is easy enough, I do not see why not, and at least an example exists.

What happpens when we want to add a column to a table which then conflicts with what someone did in their extension? If we do automatic schema evolutions is it safe or do we risk accidentally dropping a column?

[aldbr]

It is generally safer for extensions to use "has-a" relationships (new table with Foreign Key) rather than "is-a" relationships (inheriting/modifying an existing table). The systems I've looked at that provide extension mechanisms similar to ours all rely on "has-a", which we already support. See for example https://docs.djangoproject.com/en/5.2/ref/contrib/contenttypes/#generic-relations

[fstagni]

It is easy enough, I do not see why not, and at least an example exists.

What happpens when we want to add a column to a table which then conflicts with what someone did in their extension? If we do automatic schema evolutions is it safe or do we risk accidentally dropping a column?

Good points, they can be added to the documentation of existing risks.
In general, from a pure technical point of view, we can't forbid anything to be done in an extension, at the same time they are "AT YOUR RISK" changes. I agree best practice is to use "has-a" relationships.

[chrisburr]

Of course, people can also monkeypatch diracx and do anything they want.

We had said that gubbins contains examples of everything that supports being extended and if you do anything that isn't included in there you should open an issue. Until someone comes up with a valid used case, I don't think we should document things that might come to bite us.