Opened 22 months ago
Closed 9 months ago
#33817 closed New feature (fixed)
Use python-oracledb instead of cx-oracle
| Reported by: | Alexander Shishenko | Owned by: | Jingbei Li |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | dev |
| Severity: | Normal | Keywords: | oracle |
| Cc: | Florian Apolloner, Christopher Jones, Colin Murtaugh, Marti Raudsepp | Triage Stage: | Ready for checkin |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
There is a new library for Oracle databases: https://oracle.github.io/python-oracledb/.
It is intended to replace cx-oracle eventually, and it is fully compatible with it. It supports so-called “thin” mode, which can be used without installing Oracle binary client libraries.
That could be beneficial in some scenarios.
Change History (30)
comment:1 by , 22 months ago
| Cc: | added |
|---|---|
| Component: | Uncategorized → Database layer (models, ORM) |
| Keywords: | oracle added |
| Triage Stage: | Unreviewed → Accepted |
| Type: | Uncategorized → New feature |
comment:2 by , 22 months ago
| Has patch: | set |
|---|---|
| Needs documentation: | set |
| Needs tests: | set |
| Owner: | changed from to |
| Patch needs improvement: | set |
| Status: | new → assigned |
comment:3 by , 22 months ago
| Cc: | added |
|---|
comment:4 by , 20 months ago
| Needs documentation: | unset |
|---|---|
| Needs tests: | unset |
| Patch needs improvement: | unset |
I've fixed the patch, tests and documentation. And this ticket is now ready for review.
comment:5 by , 19 months ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
comment:6 by , 19 months ago
| Cc: | added |
|---|
comment:7 by , 16 months ago
| Needs documentation: | set |
|---|---|
| Needs tests: | set |
| Patch needs improvement: | set |
| Triage Stage: | Ready for checkin → Accepted |
comment:8 by , 14 months ago
| Needs documentation: | unset |
|---|---|
| Patch needs improvement: | unset |
comment:9 by , 13 months ago
| Needs tests: | unset |
|---|
comment:10 by , 13 months ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
comment:11 by , 13 months ago
| Patch needs improvement: | set |
|---|---|
| Triage Stage: | Ready for checkin → Accepted |
comment:12 by , 13 months ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
comment:13 by , 13 months ago
| Triage Stage: | Ready for checkin → Accepted |
|---|
Suraj, why did you changed the status? Oracle tests still crash with this patch, it's not ready for checkin.
follow-up: 15 comment:14 by , 12 months ago
@Mariusz Felisiak I tested this patch for oracle tests and i am not seeing any error with 19c db as well as 21c. Shall we change the status from accepted to ready for checkin?
follow-up: 16 comment:15 by , 12 months ago
Replying to Suraj Shaw:
@Mariusz Felisiak I tested this patch for oracle tests and i am not seeing any error with 19c db as well as 21c. Shall we change the status from accepted to ready for checkin?
It crashes on our setup, so it's not ready. We cannot permanently break our CI.
comment:16 by , 12 months ago
Replying to Mariusz Felisiak:
Replying to Suraj Shaw:
@Mariusz Felisiak I tested this patch for oracle tests and i am not seeing any error with 19c db as well as 21c. Shall we change the status from accepted to ready for checkin?
It crashes on our setup, so it's not ready. We cannot permanently break our CI.
In the setup integration it seems to be using 19c db. Shall we look out to upgrade it to 23c. It may or may not resolve the crash issue but it may be needed at some stage anyway.
follow-up: 18 comment:17 by , 12 months ago
In the setup integration it seems to be using 19c db. Shall we look out to upgrade it to 23c. It may or may not resolve the crash issue but it may be needed at some stage anyway.
Oracle 19c will be supported 4 more years, so I see no reason to bump it now. First of all it's really time-consuming (at least few days of my work). Secondly Oracle 23c is not officially supported by python-oracledb or cx_Oracle.
follow-up: 19 comment:18 by , 12 months ago
Replying to Mariusz Felisiak:
In the setup integration it seems to be using 19c db. Shall we look out to upgrade it to 23c. It may or may not resolve the crash issue but it may be needed at some stage anyway.
Oracle 19c will be supported 4 more years, so I see no reason to bump it now. First of all it's really time-consuming (at least few days of my work). Secondly Oracle 23c is not officially supported by
python-oracledborcx_Oracle.
Oracle 23c is officially supported and i guess it may help us to get past the crash impasse.
comment:19 by , 12 months ago
Oracle 23c is officially supported and i guess it may help us to get past the crash impasse.
Again, Oracle 19c will be supported 4 more years, so I see no reason to bump it now. We cannot drop support for it just because we don't know why it crashes with this patch.
follow-up: 21 comment:20 by , 11 months ago
@Mariusz Felisiak Any leads how shall we proceed further to this PR to land it as soon as possible since its quite long we have been waiting for this feature to be present in django.
comment:21 by , 11 months ago
Replying to Suraj Shaw:
@Mariusz Felisiak Any leads how shall we proceed further to this PR to land it as soon as possible since its quite long we have been waiting for this feature to be present in django.
As Mariusz already pointed out more than once: Oracle 19c is and still will be supported for a while. So you will need to fix the PR for Oracle 19, once that is done it can get reviewed.
comment:22 by , 11 months ago
It's not easy to fix something that doesn't reproduce, and where log files are not available !
comment:23 by , 11 months ago
Which logs would be needed? The CI job logs are public. If you think it is in the Oracle logs, please tell us which logs would be relevant or which config changes would be required to obtain the necessary logs, then it would be easier for the people having access to help you.
Maybe we can schedule a live session with someone who has access to the server and someone with knowledge of the oracle changes, so it could be debugged live?
comment:24 by , 11 months ago
We (Oracle) can assist on a live session if we can get someone who can handle the Django infrastructure questions. We span a few timezones. What's convenient? Send me email addresses (mine is in my profile https://github.com/cjbj) to invite.
comment:25 by , 11 months ago
@MarkusH: Can you or someone else from ops help out here (another option would be to temporarily give me access to the CI boxes again)?
comment:26 by , 11 months ago
I can take a look but not in June, maybe in July or August. It's not high on my priority list. I've already spent too much time in June keeping the Oracle backend as functional as the others. As far as I'm aware, it's an issue in python-oracledb or one of the libraries it uses. Of course, we will help you (Oracle) with debugging, even considering the fact that you've never helped us maintain the Oracle backend by providing infrastructure, knowledge, or money. You have to wait patiently like everyone else. It's an open-source.
comment:27 by , 11 months ago
After following the logs that has been uploaded , it looks like it is crashing inside the code that is displaying all of the variables in the stack. In the debugging code if it can be disabled it may help us to find out what the real issue is.
comment:28 by , 9 months ago
| Patch needs improvement: | unset |
|---|
comment:29 by , 9 months ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
Thanks for the report, see the django-developers thread for a discussion of potential ways to move this forward: