Add missing wait strategy to test if database containers are up and running (ODBC)

[HofmeisterAn]

Replace or extend WaitUntilPortsAreAvailable: https://github.com/HofmeisterAn/dotnet-testcontainers/blob/e23d1eb8b6ea20fbf748fa0158e67a88719415c1/src/DotNet.Testcontainers/Core/Wait/WaitUntilPortsAreAvailable.cs#L15

• PostgreSql
• MySql
• MsSql
• CouchDb
• Redis
• RabbitMq

[lukasvavrek]

Hello @HofmeisterAn, I would love to take a look at it.

Do you have something specific in mind in order to extend/replace this class? Can you point me to the right direction?

[HofmeisterAn]

I think the feature splits into two parts:

One in an additional implementation of IWaitUntil. In the implementation I would try to establish a database connection. If the connection is successful, the Testcontainer is ready for use. If the connection fails, I would try n-more times before finally throwing an exception. Unfortunately, it is not enough to test the database port availability.

The second part seems to be a bit more complicated. I would like to offer an implementation that supports as many databases as possible without additional providers. So far, I only tested a very simple implementations and had problems with Unix systems again and again. Maybe it is even necessary to fall back on the implementations of the providers and write a generic implementation with System.Data.Common. In this case I would probably prefer database specific modules. See also: .NET Framework Data Providers.

This feature does not require any special database functions. We just need to make sure that a connection is possible. Do you have any ideas for implementation?

[lukasvavrek]

Thanks for providing all the information.
I believe that the implementation of the first part is clear.

When it comes to actual connectivity testing, I would say that we could have one implementation that will work on top of the DbConnection. For providers that are not compatible with this class, we might create Db-specific implementations or let the user provide it.

What do you think?

[HofmeisterAn]

Sounds great. I think we should provide specific implementations as own modules in the future. For now, we can focus on compatible implementations.

[HofmeisterAn]

@Ta-Ja Maybe we can use a much simpler implementation. Each database container should contain everything to connect to himself. We can use this mechanism and provide provider specific scripts, e. g. for PostgreSQL we can use pg_isready. This should be very simple, and we don't need any .NET database provider at all.

[lukasvavrek]

@HofmeisterAn that looks great! I like the idea that we don't need to use a .NET DB provider. I'll take a look at it today.

[HofmeisterAn]

I've added a little test implementation for PostgreSql, looks good so far. I didn't have much time to clean up the code: https://github.com/HofmeisterAn/dotnet-testcontainers/compare/feature/implement-database-is-running.

[lukasvavrek]

@HofmeisterAn I see that you are quite far with your implementation. I tried some implementation locally based on your suggestions but it's not comparable to your work.
If you still need some help with this task, please let me know.

[HofmeisterAn]

@Ta-Ja I have made some changes in preparation for version 1.0.0 too. In most of the changes, I refactored inconsistent namespaces. Unfortunately, some changes are breaking changes.

Anyway, I'm pretty interested in your ideas and thoughts. I like to share as much as I can. Maybe you can provide some of your details.

Are you working on your four pull request for hacktoberfest? If you like we can set up a pr for your efforts.

[lukasvavrek]

@HofmeisterAn yes. I decided to take advantage of hacktoberfest and do my first OSS contribution.
I prefer not to create a throwaway PR so I'll sync with your new changes and work on top of them.

Correct me if I'm wrong, but the original idea of a wait, that'll repeat something N times and throws afterward isn't still implemented. Would it be beneficial to have it even when not used as planned for waiting for DB? If yes, I could work a bit more on it and create a PR.

What do you think?

[HofmeisterAn]

Correct me if I'm wrong, but the original idea of a wait, that'll repeat something N times and throws afterward isn't still implemented.

Yes, thats right. I took the existing WaitStrategy to implement this features. This class waits until the command is successful or throws an exception after a timeout.

Would it be beneficial to have it even when not used as planned for waiting for DB?

I'm sure it will.