Skip to content

Design question / is a hard dependency on SqlAlchemy really necessary? #336

Closed

Description

@logicbomb

Hi,

It seems that the _connect method is causing the DbContainer project to take a hard dependency on SqlAlchemy. This is troublesome for those of us not using that package. Is it meant to do more than verify the database container is up & running? If not, maybe there's a more neutral way of checking like using pg_isready?

thanks,
Jason

Activity

  1. changed the title [-]Design question / is a hard dependency on SqlAlchemy reall necessary?[/-] [+]Design question / is a hard dependency on SqlAlchemy really necessary?[/+] on Apr 18, 2023
  2. tillahoffmann commented on Apr 22, 2023

    @tillahoffmann
    Contributor

    Yes, that's a good point. We should move away from a hard dependency on sqlalchemy as you suggested. Do you have thoughts on how to integrate that change? A PR would be very welcome!

  3. logicbomb commented on Apr 22, 2023

    @logicbomb
    Author

    i thought to use popen to execute the pg_isready command, does that sound like a reasonable approach?

  4. HofmeisterAn commented on Apr 22, 2023

    @HofmeisterAn
    Contributor

    i thought to use popen to execute the pg_isready command, does that sound like a reasonable approach?

    Based on my experience maintaining TC for .NET, waiting for pg_isready to succeed is not always reliable. There were instances where the .NET Npgsql client could not establish a connection. Since I wait for specific log messages, I have not encountered any connection issues.

  5. logicbomb commented on Apr 22, 2023

    @logicbomb
    Author

    I put together a WIP here: https://github.com/logicbomb/testcontainers-python/pull/1/files

    You can see 2 possible implementations, one based on pg_isready the other checking logs as described by @HofmeisterAn. Using pg_isready is much less code and seems to work, but I'm happy to go with either.

    Also, would you all require a change to the way all databases are verified, or would you accept a change only for Postgres?

  6. tillahoffmann commented on Apr 23, 2023

    @tillahoffmann
    Contributor

    You may want to have a look at the wait_for_logs function here. That should reduce the amount of code required.

  7. logicbomb commented on Apr 23, 2023

    @logicbomb
    Author

    ooh, wait_for_logs is nice. i take it you prefer that approach?

  8. 1 remaining item

  9. logicbomb commented on Apr 23, 2023

    @logicbomb
    Author
  10. added a commit that references this issue on Mar 11, 2024
    f30eb1d
  11. added a commit that references this issue on Mar 11, 2024
    940167e
  12. added a commit that references this issue on Mar 30, 2024
    0f79144
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions