search

testcontainers / testcontainers-dotnet

A library to support tests with throwaway instances of Docker containers for all compatible .NET Standard versions.
https://dotnet.testcontainers.org
MIT License
3.67k stars 254 forks source link

feat: Add Firebird SQL module #1073

Closed park-jasper closed 6 months ago

park-jasper commented 7 months ago

What does this PR do?

Adding Testcontainers.FirebirdSql project that allows to use Firebird SQL with Testcontainers

Why is it important?

Firebird SQL is not supported for Testcontainers .NET yet. There is support for Testcontainers Java on the Firebird Repository (https://github.com/FirebirdSQL/firebird-testcontainers-java) which these changes are based on.

Related issues

none

How to test this PR

I created unit tests that test against the four tagged versions 2.5-ss, 2.5-sc, 3.0, 4.0 This is because the 2.5 versions behave differently and as such I wanted to ensure all the currently available versions will work.

Comment

The code is based on the implementation of the MsSql project and the mentioned firebird-testcontainers-java repository. I am open to discuss if this is the right place or rather the firebird repository.

netlify[bot] commented 7 months ago

Deploy Preview for testcontainers-dotnet ready!

Name Link
Latest commit 6990cb388d3b00e7f44135572a32a4ee599823cd
Latest deploy log https://app.netlify.com/sites/testcontainers-dotnet/deploys/65942b1c7205300008d29cd0
Deploy Preview https://deploy-preview-1073--testcontainers-dotnet.netlify.app
Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

HofmeisterAn commented 7 months ago

Thank you for the PR. I haven't had the time to review it yet, but I will do so in the coming days.

HofmeisterAn commented 7 months ago

Thank you for addressing the comments. I have made some minor changes to ensure the module aligns with the other modules. I left three additional comments, and happy to merge the PR soon, once those comments are addressed. Thank you again.

park-jasper commented 7 months ago

Thank you for addressing the comments. I have made some minor changes to ensure the module aligns with the other modules. I left three additional comments, and happy to merge the PR soon, once those comments are addressed. Thank you again.

Thank you for your commits. I ran into an issue where the path to the database does not need to be modified with the /firebird/data path when using EntityFramework instead of the raw SqlConnection. I am still trying to figure out why that is. Until I can figure that out we should leave the PR open, it seems I prematurely opened it. I may ask/involve someone from firebird on that topic and see what is up with the different ways the provider behaves.

HofmeisterAn commented 7 months ago

Thank you for addressing the comments. I have made some minor changes to ensure the module aligns with the other modules. I left three additional comments, and happy to merge the PR soon, once those comments are addressed. Thank you again.

Thank you for your commits. I ran into an issue where the path to the database does not need to be modified with the /firebird/data path when using EntityFramework instead of the raw SqlConnection. I am still trying to figure out why that is. Until I can figure that out we should leave the PR open, it seems I prematurely opened it. I may ask/involve someone from firebird on that topic and see what is up with the different ways the provider behaves.

If we figure out the correct wait strategy, I think we can merge the PR in the meantime (if you like). We can then update the configuration to work with EF afterward.

park-jasper commented 7 months ago

Thank you for addressing the comments. I have made some minor changes to ensure the module aligns with the other modules. I left three additional comments, and happy to merge the PR soon, once those comments are addressed. Thank you again.

Thank you for your commits. I ran into an issue where the path to the database does not need to be modified with the /firebird/data path when using EntityFramework instead of the raw SqlConnection. I am still trying to figure out why that is. Until I can figure that out we should leave the PR open, it seems I prematurely opened it. I may ask/involve someone from firebird on that topic and see what is up with the different ways the provider behaves.

If we figure out the correct wait strategy, I think we can merge the PR in the meantime (if you like). We can then update the configuration to work with EF afterward.

That sounds good, I will take a look at open comments and issues (next week) and we can incrementally improve this.