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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…
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…