Add Oracle support

no i think actually it cannot use the driver. It was working with drupal 6.x. I've not looked at it too mutch yet...

may be you can try asking on the drush project.. i'dont know drush very well, in my experience syslog() and debug_backtrace() functions are really usefull tools to understand how a piece of php code works.

Look at drush_valid_db_credentials() in includes/environment.inc

Yes; drush supports mysql, pgsql, sqllite, and sql server support is in progress. Oracle is unsupported; some work, including but not limited to #6 would be required to get it to work.

@sionescu we only accept new functionality primarily in the 5.x branch, and after it gets in it may be backported to 4.x. Also see this issues for reference: #1050030: sqlsrv PDO driver uses invalid connection string

ps. you need to set "needs review" when you post a patch.

I don't know what to say about #9, but the code in #8 looks good in concept. It needs to be rolled against the master branch (drush-5.x), and should support both Drupal-6.x and Drupal-7.x prior to commit. This won't get you sql-dump et. al., but we could start here.

@sionescu: Maintainers are a lazy bunch; when we see something like Hunk #1 FAILED at 1215. from the patch command, we usually want the original submitter to reroll (recreate) the patch so that it applies to the most recent version without errors. Your patch does not apply to the head of the 7.x-4.x or the master branch, or even to the 7.x-4.4 branch. Please submit a new patch against master.

@sionescu please see issue #1050030: sqlsrv PDO driver uses invalid connection string where support for other database (sqlsrv) was implemented. There're other places of drush where code is needed to fulfill oracle support.

Also, review your code to not include trailing whitespaces.

I've created a new patch that builds on the work in comments/patches #17 and #18. I tried to incorporate the method used to bring in sqlsrv support as much as possible. The following drush commands work for me with Oracle 11.2 :

drush sql-query (with special help for describe and show tables queries)
drush sql-cli
drush status
drush pm ... (enable modules etc)
drush ws (watchdog stuff)

Many of the other features work as well. I've also put some time into best guess formatting for output from sqlq queries.

I didn't get sql-dump or sql-drop working, mostly due to the complexities of Oracle's constraints -- and that it would have to integrate the exp and imp utilities. I'll try to add those in a bit, I have my own scripts to do those functions that could probably be worked into drush. I haven't tested the sync stuff yet either and am sure it won't work because table dropping is not implemented.

I haven't tested Drupal 7 yet, and I'm sure work will need to be done there. I've also added support for rlwrap which gives readline support if you have rlwrap installed (unix only, sorry).

This patch is against the latest 5.x master. Use at your own risk, I'm posting this just to keep the development going, not ready for production sytems! Hope it moves us further along.

Setting status to Needs Review for patch in comment #20.

+++ b/commands/sql/sql.drush.inc
@@ -225,6 +225,15 @@ function _drush_sql_connect($db_spec = NULL) {
+      } else {

else must use 2 lines per drupal coding standards.

+++ b/commands/sql/sql.drush.inc
@@ -890,6 +911,13 @@ function _drush_sql_get_credentials($db_spec = NULL) {
+      // Some drush commands (e.g. site-install) want to connect to the
+      // server, but not the database.  Connect to the built-in database.
+      return ' ' . $db_spec['username'].'/'.$db_spec['password'].'@//'.$db_spec['host'].':'.$db_spec['port'].'/'.$db_spec['database'];

comment does not match code?

+++ b/commands/sql/sql.drush.inc
@@ -975,6 +1003,37 @@ function drush_sql_show_tables_pgsql() {
+ ¶

leading space

+++ b/includes/filesystem.inc
@@ -344,6 +344,15 @@ function drush_tempnam($pattern, $tmp_dir = NULL) {
+
+  // oracle needs .sql extensions
+  $creds = drush_get_context('DRUSH_DB_CREDENTIALS');

oracle cares about file extension?????

I'll re-roll patch #20 with those corretions, thanks Moshe. But yes, oracle does care about scripts ending in .sql. You can set the extension, but I could not find a way to say "no extension" -- it has to be something. That comment was repeated throughout for the other cases, I'll just edit it.

I've re-rolled this patch against the latest "master". I think the issues are fixed from #22. I cannot find a way to get around the file extension issue with oracle, I think it's a legacy thing.

Sorry I didn't review the earlier patches sooner, but I just took a look at #24 and came up with a necessary change:

@@ -344,6 +344,16 @@ function drush_tempnam($pattern, $tmp_dir = NULL) {
     $tmp_dir = drush_find_tmp();
   }
   $tmp_file = tempnam($tmp_dir, $pattern);
+
+  // Oracle seems to need .sql extensions
+  // I have not found a way to specify no extension
+  $creds = drush_get_context('DRUSH_DB_CREDENTIALS');
+  $type = $creds['driver'];
+  if ($type == 'oracle') {
+    rename($tmp_file, $tmp_file.'.sql');
+    $tmp_file .= '.sql';
+  }

I don't like using the DRUSH_DB_CREDENTIALS context to alter the behavior of drush_tempnam. This code could cause an undesirable side-effect in callers that are using drush_tempnam for purposes other than an sql import. While there is no operational problem with a spurious ".sql" on the end of a temp file, it could be confusing to see it there. I also would not want to see this coding style spread to other parts of the code where the impact might be greater.

Instead, the function prototype of drush_tempnam should be altered:

function drush_tempnam($pattern, $tmp_dir = NULL, $extension = '')

Insure that any code path that calls drush_tempnam from a context where it will end up being used with Oracle passes '.sql' for $extension.

Do you want me to resubmit a patch for drush that changes the prototype for drush_tempnam? I don't want to overstep.

Yes. If you provide a default parameter as shown above, you will not break existing code. I think that the enhancement is generally useful.

refactored cschaub patch... probably we don't need to change drush_tempnam.
tested against the master branch

Thanks cschaub!

Looks good to me. Lets wait a couple days for feedback.

I'll test it out, thanks! I was not able to find time to rewrite the tempnam stuff.

re #20 if sql-dump and sql-drop are not supported, the user should be informed. At execution time better than in the help.

starting from my patch sql-dump and sql-drop are supported

I made the tempnam changes and committed this.

Cannot bootstrap oracle in Drupal 6, moved PDO driver name translation only for drupal >=7

committed

Added sql-sync support for oracle

Looks pretty good. Note that $create_db_file is not cleaned up on the remote machine, in cases where the target is remote; it is only cleaned up on the source machine. Temp files should be cleaned up in all locations where they are written.

fixed it

The table creation code is so verbose!

I have been OK with the messiness for a while but it would be really nice if we could move DB suport engine system and let oracle/sqlserver live in Contrib. I guess thats a future patch.

Also, it would be nice if someone ran the test suite with sqlserv and/or oracle and fixed any failures. At one point, the suite passed with pgsql and mysql so it can be done.

Would be ideal if someone could verify that this patch works.

I'm seeing some strange behaviour enabling modules. With my patch, modules enable correctly, and they do from the web interface as well. When I enable them with this latest version, the wrong modules get enabled! Devel gets enabled, openid, etc ... and I'm just enabling webfm or a custom feature. I think there is something amiss.

During development a new version of pdo_oci driver (http://drupal.org/project/pdo_oci), I found that Drupal installation works but drush fail. It is because:

1. We are using $creds['database'] but not $creds['name']
2. charset=AL32UTF8 will no long works with php-5.4
3. Most switch cases just take care about 'oracle' (which is incorrect with pdo_* style), but wrongly ignore cases for 'oci' (i.e. the correct style for pdo_*)

A quick fix attached with a bit coding style clean, too.

Also fork to github as https://github.com/pantarei/drupal-drush/tree/7.x-5.x-1180240

I'm very interested in seeing Drush fully support Oracle, When can we expect these fixes to be merged back into the main branch?

This issue was marked closed (won't fix) because Drush has moved to Github.

If desired, you may copy this bug to our Github project and then post a link here to the new issue. Please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.