Currently looking to see if I can replace our usage of devart oracle dotConnect commercial DAP as part of updating to net core and ormlite and have a couple of questions.
The dotConnect express currently used contains some restrictions that make it unusable for my needs (direct access prohibited IIRC)
Are there reasons to not use Oracle.ManagedDataAccess and Oracl.ManagedDataAccess.Core such as licensing/comparability or other that were found?
Is there any plans to use these already underway?
If neither of the above, would PR’s even be welcome for this?
As a representative of the folks who have done most of the updates to the Oracle provider for OrmLite for the last couple of years, I will say that:
the .NET framework Oracle ManagedDataAccess works fine unless you need transaction tracking across database connectivity issues/restarts which it does not support.
we would welcome a port to .NET core. The only reason we aren’t working on it is that converting to .NET core is not at present viable for us, completely independently from the Oracle provider.
Yeah we don’t maintain the Oracle provider at all which has mostly been maintained by @bruce (and team) up till now who you should consult with for any proposed changes.
Just to be clear, that transaction tracking is to handle the situation where a transaction completes successfully but database connectivity is lost before that result can be sent to the client. ODP.NET supports such transaction tracking, I don’t know about dotconnect express. OrmLite, however, does not, so if one wants to use it, it requires some custom effort. We don’t use it in our application, so I really can’t speak to it any more than that. IMO if you need that level of support/complexity, OrmLite is not really the ORM you should be using.
I have a question about the tests for the Oracle provider. A lot of the tests are failing with Returning last inserted identity is not implemented on this DB Provider
It makes sense as I see it uses sequences to get the next value and assign this to the AutoIncrement assigned property and the provider has no way of conforming to the identity aquistion convention in the underyling provider base class.
Conforming to the default convention might be possible from v12 onwards which added Identity as a kind of thin veneer over sequences so it could be worth creating a similar convention to the SqlServer dialects for version specific functionality.
Whilst selectIdentity is an optional param of insert to avoid calling the provider’s GetLastIdentity method, the Save method contains no ability to specify this.
So to get to the point … I’m wondering how do the tests pass when they are using db.Save() rather than db.insert() when the provider can’t obtain identities using the default convention?
I have to admit it has been some time since we ran the tests (we’re still using 4.5.12 of ServiceStack for various reasons). As you point out, conforming to OrmLite’s last inserted identity convention is not strictly possible when using sequences, but my hazy memory says we implemented an ugly hack to make the most common use case work and the tests pass.
It definitely would be a good idea to add v12 support similarly to how SqlServer dialects work.
Sorry I can’t be more helpful than that, but I don’t have the time right now to look into this more, because the context switch would cost me too much.
