steffres

Forgot to add, that those can be concatanated, e.g. `__o_car__t_finances`.

I do this manually by appending `__t_tag`, where `t` is a category and `tag` the value.

E.g. `__o_car`, where `o` means object, or `__p_supercode`, where `p` = project, `__t_ml`, where `t` = topic, ml = machine learning, etc.

No dependencies, hardcoded into the files forever, and search is reasonably fast too (don't need it that often anyway).

I simply rinse my wooden boards with boiling water after cutting meat on them (and then wash them of course).

oh, you're right. I forgot that a key characteristic of anything being "declarative" is that order of statements should not matter.

Acutally, come to think of it, since `RUN` may depend on any other Dockerfile statement (even `EXPOSE` might make a difference in code), does this mean that even a single imperative statement that is introduced in some language, makes the language imperative?

I didn't mean to use Django _and_ a separate migration tool. It's just that I did work with Django so far, but switching now to a new codebase without it. Hence my question for experiences in DB migration.

I see. Thanks for the clarifications.

And these DB migrations, did your team keep a history of them? If so, did you manage them yourselves, or did you use some tools like flyway?

I'm asking because I'm starting a project where we will manage the persistence SQL layer without any ORM (always did it so far with Django's migrations), but might consider some third party tools for DB migrations.

That sounds reasonable. But what about the case where the DB migration of version 2 would be incompatbile with code version 1, e.g. a column was dropped?

I'd say both.

Some is declarative, e.g. `FROM`, `ENV`, `EXPOSE`. While on the other hand `RUN`, `CMD`, etc. is fully imperative.

yes, if one submodule would depend on another, this would cause problems indeed.

So far, we could avoid it though, by strict encapsulation.

But I definitely see the point in your example and wouldn't follow through with submodules there probably too.

It's just that in OP's link, I'm quite sceptical as the monorepo approach requires quite some heavy tweaking.

In our case, we have a codebase that involves two submodules: one for persistence and one for python based management of internal git repos. Both of these are standalone applications and can run on their own. They are then used in a parent repo which represents the overarching architecture, which calls into the submodules.

The advantage of this is, that work can be done by devs on the individual modules without much knowledge of the overarching architecture, nor strong code ties into it.

Right now our persistence is done with SQL, but we could swap it with anything else, e.g. mongo, and the parent codebase wouldn't notice a thing since the submodule only returns well defined python objects.

Of course, this comes at the cost of higher number of commits as you mentioned. But in my opinion these are still cheap because they only affect trivial quantity and not brain-demanding quality.

for each submodule affected by some change you would need an additional commits, yes. But those commits are bundled together in the commit of the parent repo where they act as one.

So, atomicity of changes can be guaranteed, but you need to write a few more commits. However this effort of small increases of commits is far outweighed by the modularity imo.

Anyone know, what's the advantage of this over a big composite repo with several git submdolues?

I think that submodules are better suited for separation of concerns and performance, even while achieving the same composite structure as an equivalent monorepo?