rebus-org / Rebus.Oracle

:bus: Oracle transport for Rebus
https://mookid.dk/category/rebus
Other
5 stars 10 forks source link

Transactions #24

Closed jods4 closed 5 years ago

jods4 commented 5 years ago

Rather large refactoring of connection and transaction management. This is my last changes in preparation for #13.

⚠️ Several objects I modified where public, so this PR is a big breaking change. In practice I don't expect end users to use those objects directly, but unfortunately this assembly exposes a lot of stuff publicly.

✔️ 79/79 tests are green

mookid8000 commented 5 years ago

hey @jods4 , it's hard for me to keep up with you.... would you be interested in becoming an official maintainer of Rebus.Oracle (and possible on other things too, because you have lots of great ideas)? Hit me up on mogens@rebus.fm, if you're interested

jods4 commented 5 years ago

@mookid8000 Don't worry, I'm almost done! Last thing I want is to add #13 and I'm gonna stop submitting PR like crazy :)

It seems you did not actually publish a4 as I can't find it on github. It's causing me a lot of pain as a3 is not compatible with 6.0... Can you please merge this and publish a new nuget package? Thanks! 🙇

BTW: I had one flaky test run, where I got a duplicate id during DataBus tests. I can't reproduce it for now. You said databus id should be unique, but I asked about it since the databus code kind of worked around the idea that a databus id might have duplicates. Any idea?

It was test CanGetStandardMetada. OracleDataBusStorage.Save failed because of ORA-0001 unique key violation DATABUS_PK. That indicates non-unique id... weird?

mookid8000 commented 5 years ago

cool! 👍

I've pushed Rebus.Oracle 2.0.0-a5 now... should appear on NuGet.org within a few minutes

jods4 commented 5 years ago

Don't bother with the bug...

Test that failed uses a fixed id: https://github.com/rebus-org/Rebus/blob/master/Rebus.Tests.Contracts/DataBus/GeneralDataBusStorageTests.cs#L110

I interrupted a test run just before, so my guess is that it was during this test and the underlying table did not get cleaned.

In practice Rebus generates a new guid just before sending the attachment, so this can't happen. False alarm!