I have a simple query that checks to see if the external oracle database is accessible. It runs on the Status Report page. That page now gives WSOD.
I also have other queries that now fail when updating to 7.x-1.10. It complains of an unknown table, but it works fine with 7.x-1.9.
I'm running Drupal 7.12, and the Oracle database I'm connecting to is NOT my main Drupal database. It's an external data warehouse. That's why the rest of the site works fine until I try to run those queries.
I'm trying to step through the code with a debugger to find where it fails, but I haven't found it yet.
Comments
Comment #1
aaaristo commentedcan you post the error please?
Comment #2
aaaristo commentedtry 1.11
Comment #3
shawn dearmond commentedOn 1.11, here's the error I get on the Status Report page:
And when I run my tests, I get this:
It works fine with 1.9.
Comment #4
aaaristo commentedlooks like {acad_term} is not transformed. This because from 1.10 external databases are no more treated as drupal backends. You probably don't need the {table} notation in the query right?
Comment #5
aaaristo commentedComment #6
shawn dearmond commentedAha! That would definitely make sense. Drupal habits are hard to break!
I'll mark it as resolved when I confirm that it's the issue.
Thanks!
Comment #7
shawn dearmond commentedOkay, so here's the problem: I'm using PDO to do the queries. For example, my hook_requirements query that's causing the first error is:
I'm not entering the transforming notation, Drupal is. Is there a way I tell Drupal that it's an external database so it won't wrap the table names in curly brackets?
Comment #8
aaaristo commentedcommited in -dev...
ps: it is not up to you how i manage my issue list...
Comment #9
shawn dearmond commentedThat fixed the first error on the status report page, but I'm still getting an error when I run my tests... which I fully admit could be bad code or bad tests on my part. I'm just curious as to why it's suddenly failing with version >= 1.10.
Here's the error I'm getting when I run my tests:
ps. Sorry, I don't mean to step on anyone's toes. Just trying to be helpful.
Thank you for your attention to this issue, by the way, and for maintaining this module.
Comment #10
shawn dearmond commentedI figured it out. It had to do with one more of those escaping methods and how they're not being run when $this->external. Specifically: $oquery= $this->escapeCompatibility($oquery);
Attached is a patch that fixes that one, and cleans up that section of the code a little, but now I'm wondering if maybe the rest of those escape*() methods should be run, even on external databases. My tests all pass now (with this patch) but it's likely I'm not using all aspects of PDO.
What is your reasoning for not running these escape*() methods on external databases?
Comment #11
aaaristo commentedRight, i've exclude the escape methods as a result of this bug: http://drupal.org/node/1167524,
thinking that if you ar going to access an external on oracle database you know it.. and so you'll write
oracle compliant sql. But probably i should have removed only the $oquery= $this->lih->escapeLongIdentifiers($oquery);,
because even if you are accessing an external oracle database you may want to use the dbtng framework
to access it (like you do with db_select). So yes i am going to fix it in -dev.
ps: sorry, yesterday was a bad day... thanks for the feedback
Comment #12
aaaristo commentedcommitted in -dev
Comment #13
shawn dearmond commentedWorks perfectly. Thanks!
If you could roll a release so I can implement it on my production site, I'd really appreciate it. Thanks again for being so attentive to your issue queue. It's a remarkably rare quality.