You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
What class to use to implement or migrate database modules #884
Most modules use the testcontainers.core.generic.DbContainer class, but it is marked as deprecated, should we use testcontainers.generic.ServerContainer?
DbContainer had a couple of generics for most databases like uri creation and sqlalchemy connect in _connect, do we just lose that and every module needs to implement their own or would it be ok to re-implement DbContainer from ServerContainer to keep the database specific things?
DbContainer is great but the idea was to move to a more generic hierarchy where we can extend ServerContainer to things like DbContainer. The old testcontainers.core.generic will be removed eventually after a proper replacement been made, something like modules.generic.testcontainers.generic.db (I imagine) that users can migrate from DbContainer with ease 😊
I'm not sure that inheriting DockerContainer -> ServerContainer -> DBContainer makes sense, ServerContainer is just an HTTP specialization of DockerContainer, while some database might implement HTTP most don't.
i think the deprecation may be pre-mature in that there is no real alternative right now but it does represent the opinion that we do not want to rely on a sql health check or build the urls the same way for all databases. i think both of these remain bad assumptions. if you want to use them for now i think that is fine - esp if it is merged in here because i will clean that up when we get around to it. i dont want to make people install sqlalchemy if they dont have to. if it is useful for cratedb, lets add it as an optional dependency for the "crate" extra (pip install testcontainers[cratedb])
DockerContainer -> ServerContainer -> DBContainer is not the direction, sorry if that got lost on the way, DBContainer just should not be part of core.. but as a module like modules.generic.testcontainers.generic.db and doesn't have to include ServerContainer in any way, hope that help to clarify.
(I'll try to get a draft ready soon)
The idea/philosophy here that core should not include specific modules (even if we add the word "generic" to them 😅), those are just more modules that we can handle and maintain under modules.generic
Activity
Tranquility2 commentedon Sep 30, 2025
DbContaineris great but the idea was to move to a more generic hierarchy where we can extendServerContainerto things likeDbContainer. The oldtestcontainers.core.genericwill be removed eventually after a proper replacement been made, something likemodules.generic.testcontainers.generic.db(I imagine) that users can migrate fromDbContainerwith ease 😊surister commentedon Sep 30, 2025
Sounds good, is there any issue where we can find the plan for
modules.generic.testcontainers.generic.dbsurister commentedon Oct 1, 2025
I'm not sure that inheriting
DockerContainer -> ServerContainer -> DBContainermakes sense,ServerContaineris just an HTTP specialization ofDockerContainer, while some database might implement HTTP most don't.alexanderankin commentedon Oct 1, 2025
i think the deprecation may be pre-mature in that there is no real alternative right now but it does represent the opinion that we do not want to rely on a sql health check or build the urls the same way for all databases. i think both of these remain bad assumptions. if you want to use them for now i think that is fine - esp if it is merged in here because i will clean that up when we get around to it. i dont want to make people install sqlalchemy if they dont have to. if it is useful for cratedb, lets add it as an optional dependency for the "crate" extra (pip install testcontainers[cratedb])
Tranquility2 commentedon Oct 2, 2025
DockerContainer -> ServerContainer -> DBContaineris not the direction, sorry if that got lost on the way,DBContainerjust should not be part of core.. but as a module likemodules.generic.testcontainers.generic.dband doesn't have to includeServerContainerin any way, hope that help to clarify.(I'll try to get a draft ready soon)
The idea/philosophy here that core should not include specific modules (even if we add the word "generic" to them 😅), those are just more modules that we can handle and maintain under
modules.genericTranquility2 commentedon Oct 2, 2025
Please checkout #892
surister commentedon Oct 3, 2025
I think that the information provided in this issue is enough to answer the original question, thank you very much!
feat(generic): Reintroducing the generic SQL module (#892)