This issue was originally a comment on:
I've moved it here (hopefully the right queue) since the DBTNG issue is fixed.

Posted by neclimdul on October 27, 2010 at 12:58pm

applied patch and ran the VersioncontrolAccountStatusTestCase test. Everything passed!

Did get a small exception at the end though:
Exception Uncaught e 1516
The specified database connection is not defined: default

Looks like maybe we're trying to reset to the default database connection at the end of the test but it isn't working correctly.

Members fund testing for the Drupal project. Drupal Association Learn more


eliza411’s picture

Issue tags: +git phase 2
sdboyer’s picture

Status: Active » Postponed (maintainer needs more info)

We'll see if this is still an issue after the tests actually start working. My suspicion is that's either an error related to prefixing that is just a plain ol' DBTNG problem, or could be an error that DBTNG shows when a test throws a fatal error (which the test in question was doing at that time, I believe).

So, marking postponed until we know more.

neclimdul’s picture

My guess actually having looked at 0 code from the dbtng module is that its because I just set $db_url as a string not an array. Actually I can probably test this by making it an array. Will report back...

marvil07’s picture

neclimdul’s picture

Title: VersioncontrolAccountStatusTestCase Exception: The specified database connection is not defined: default » Exception: The specified database connection is not defined: default

This actually happens at the end of every test, sorry. That's just the test I was running to test the other issue and is an artifact of that. Updated title to reflect this.

neclimdul’s picture

So, this may very well be a simpletest issue but since its so hard to get fixes in dbtng might just have to work around it. Also, this is actually really important because this exception is a symptom of a bigger problem.

It boils down to this, dbtng_init() sets up the $databases global that's used by the rest of the library for connecting to the database. Since its never called when running simpletests, those tests will always throw this exception as soon as we try to use dbtng. This isn't caught and throws us out of the testing loop. This means any further tests are also not run.

I'm pretty sure this is totally wrong but I put

    if (empty($databases)) {
      dbtng_init(); // force something into databases...

directly after global $databases; in parseConnectionInfo.

neclimdul’s picture

Project: Version Control API » DBTNG
Version: 6.x-2.x-dev » 6.x-1.x-dev
Component: API module » Code
Status: Postponed (maintainer needs more info) » Needs work

Moving this to dbtng since mikey_p said he could make a patch.

marvil07’s picture

Status: Needs work » Needs review
943 bytes

Finally I could run a test(#914392-11: While testing, default prefix is used instead of simpletest prefix by dbtng-driven queries ) with dbtng without versioncontrol! (and I could never reproduce the exception mentioned here :-/)

But I am receiving an array on $databases global variable with the db info, but not with the right prefix, that's why I had to remove the conditional.

attached as patch to help test.

But this problem seems to be at simpletest, why simpletest module is not calling hook_init()?

marvil07’s picture

I want to share a conversation I had some minutes ago at #drupal-contribute:

marvil07 is hook_boot called at simpletest tests?
marvil07 s/hook_boot/hook_init/
carlos8f marvil07: that's a good question, i don't think hook_init() fires in the test method, but it does inside drupalGet(), etc.
marvil07 carlos8f: that would make sense if simpletest does not bootstrap(which AFAI could read doesn't)
carlos8f marvil07: if you need to test a hook, the best thing is to trigger full requests with drupalGet() etc., and use a test module. that way you ensure that all the normal hooks run, i.e. hook_init
carlos8f marvil07: so no, hook_init() isn't meant to be called for you in the test method
marvil07 carlos8f: thanks for the feedback, my problem is that I am dealing with a module(versioncontrol) that depend on another module that use hook_init(dbtng), and I need to prove CRUD is working fine without the UI
carlos8f marvil07: if dbtng depends on init, you would be suited to create a test module and test it inside a menu item, triggered with drupalGet or post.
marvil07 carlos8f: yep, or manually call its hook_init :-p
carlos8f marvil07: i wouldn't recommend that :)
marvil07 carlos8f: great, I think now is clear :-), are you ok if I copy this lines to the related issue?
carlos8f marvil07: no problem

Another solution could be move the code at hook_init() to hook_boot() and ask simpletest module to call manually hook_boot() at DrupalWebTestCase::setUp().

neclimdul’s picture

Actually, I'm thinking dbtng might have a case for providing its own test type. I don't agree that manually calling dbtng_init is a bad idea in the context of dbtng testing but I do agree that requiring tests do it is less than ideal.

I'm not sure why we can't just lazy load like this though. It means dbtng is more resilient to different uses.

Also, I think the if (empty($databases)) { is a good thing as it keeps $databases from always being rebuilt.

// make sure we have the right databases
// aka make simpletest know about the right prefix

I think this is actually incorrect. It makes sure dbtng knows where the database is and recover in situations where dbtng_init() has not been called like in tests. Custom bootstraps or calls in hook_boot are other places that could have this problem.

mikey_p’s picture

Priority: Normal » Major

I think this is the correct conclusion. neclimdul is right that it's just an issue of hook_init not being called. When I first ported dbtng I figured that was the logical place to put the code to parse the D6 connection string, and that has generally been true, since I was trying to patch the actual files from D7 as little as possible, and it's worked fine most of the time until now. I'll add this check in to make sure that the $database connection info is re-parsed at the last available moment before DBTNG tries to make a connection.

marvil07’s picture

Ok, since calling hook_init() manually on test seems like a good idea for neclimdul and me, I just have done that from a DBTNGTestCase base class, where I am also removing the connection after each test to avoid problems with prefixes. See #914392-18: While testing, default prefix is used instead of simpletest prefix by dbtng-driven queries for the patch.

Not really sure if this issue this original disappears applying that patch, @neclimdul: can you confirm that?

mikey_p’s picture

Issue tags: -git sprint 3 +git sprint 4

pulling forward to sprint 4

mikey_p’s picture

Assigned: Unassigned » mikey_p
mikey_p’s picture

Status: Needs review » Fixed

There is no more hook_init, and the database connection info is parsed when needed inside Database::parseConnectionInfo().

Status: Fixed » Closed (fixed)
Issue tags: -git phase 2, -git sprint 4

Automatically closed -- issue fixed for 2 weeks with no activity.