Lets be realistic should Oracle even be supported at all - the stats
suggest not

On 25 October 2016 at 23:04, orware notifications@github.com wrote:

Steps to reproduce the issue

PHP7 and a desire to connect to an Oracle database.
Expected result

It should work, but currently the Oracle Database Driver included within
Joomla is using the PDO_OCI extension's functions, rather than the OCI8
extension.

I learned a few months back that the PDO_OCI extension isn't really well
supported under PHP 7 and there seemed to be a strong likelihood that
wouldn't change in the near future, so in order to better support those
building extensions potentially connecting to Oracle databases I'm going to
work on an OCI8 version to contribute back to the project.

Some references for the issue:
http://stackoverflow.com/questions/37191161/install-pdo-oci-on-php7
yiisoft/yii2#10975 yiisoft/yii2#10975
Actual result System information (as much as possible) Additional comments

Since I'm just starting the process at the moment, I'm wondering if I
should go ahead and do so from within the Joomla CMS repository or whether
I should update a separate Database Framework/Platform package that's
located elsewhere?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#12560, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8ZHFCbCRpOSHlJO8stYAY62CyJw1ks5q3nz9gaJpZM4KgifI
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

Hi Brian,

This is not a matter of whether anybody will run Joomla on Oracle (I certainly don't expect anybody too and I don't use Oracle as a platform for running Joomla).

But from an extension building standpoint it's certainly very useful to be able to connect to an Oracle database in my workplace since that's where most of our useful data is housed, so having the Oracle driver available allows me to build Joomla extensions that utilize an Oracle database for retrieving information and that's primarily what I use it for: running queries against an Oracle database and retrieving data and then integrating that into an overall Joomla extension that is likely using MySQL to do everything else.

Sorry I clearly didnt understand your original comment as meaning "connecting to oracle" as an external data source

I'm going to submit a pull request soon so I can start taking a look at the code cleanup suggestions that Travis provides, but currently things are working pretty well with what I have at the moment using the OCI8 functions.

The existing PDO Oracle Driver, Query, and Iterator classes were renamed to pdooracle.php so that the new versions using the OCI8 functions could use the oracle.php names.

Things I've tested so far on my end:

• getTableColumns() - Added support for when the toLower() flag is true
• getTableCreate() - Fixed bind variable bug and improved method so it could support a schema being provided as part of the provided table name.
• getTableKeys() - Added in an extra join to pull in the columns that go along with the constraints being pulled in.
• getTableList() - Tested and added in a call to UPPER() within the query
• getVersion() - Working
• insertid() - Not supported in Oracle
• isSupported() - Updated to check existence of oci_connect
• select() - Currently doesn't do anything, but could potentially be setup to switch to a different User's Schema within Oracle, which is roughly equivalent to selecting a different database.
• setQuery() - Seems to be working correctly from my tests. Tested both a directly provided query string, and passing in a query object, both with and without bind parameters and all cases worked.
• setDateFormat() - Driver uses's MySQL Date Format by default instead of the default Oracle date format. Tested out switching back to default Oracle date format and results came back with the switched date format correctly.
• setUtf() - No change
• escape() - Not really used on the Oracle side, since bind parameters are preferred.
• execute() - Tested pretty thoroughly
• getNumRows() - Integrated oci_num_rows() calls into fetch and execute methods and cache the results into a variable
• getAffectedRows() - Same as above
• replacePrefix() - Slight differences between this version and the one in the main Driver class (not sure if the differences are there on purpose or if we can simply remove this method). Need to check.
• fetchArray() - Pretty well tested
• fetchAssoc() - Pretty well tested
• fetchObject() - Pretty well tested
• freeResult() - Pretty well tested
• getErrorNumber() - Pretty well tested
• getErrorMessage() - Pretty well tested

Pending (TODO and/or Not Tested Yet, partially because I don't normally utilize these particular features):

• transactionCommit() - TODO
• transactionRollback() - TODO
• transactionStart() - TODO
• dropTable() - Not Tested
• lockTable() - Not Tested
• renameTable() - Not Tested
• unlockTables() - Not Tested
• getCreateDatabaseQuery() - Not Tested

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/12560.}

Went ahead and cleaned up the Codesniffer errors reported by Travis CI already so it should be showing the green light currently over on Github for the PR.

So we can close here as we have a PR?

Hi @zero-24, if that's how it works that should be ok. I could post the rest of my updates over on the PR page.

If we have a PR we close the issues. So we don't have dublicate places to discuss. Closing than. Thanks!