Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Installing SilverStripe /

Getting SilverStripe up and running on your computer and on your web server.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Trouble with DataObjects after pear upgrade?


Reply


3 Posts   1748 Views

Avatar
sychan

Community Member, 5 Posts

3 February 2010 at 1:25pm

Edited: 03/02/2010 1:38pm

Hello,
I'm getting up to speed on the latest release of SilverStripe and came across a problem after going through a couple of tutorials and then using pear to install PHPUnit. I'm running Silverstripe 2.3.5 with MAMP 1.8.4
I had been trying to run the /dev/tests/all stuff to see what the output was like, but it would not run, complaining that PHPUnit was not installed. After tracking down where MAMP puts pear, and upgrading pear and installing PHPUnit, I am unable to get silverstripe to run at all - all that happens once I enter the silverstripe directory is a "Website Error"

It looks like there is some issue with the DataObject connecting to the mysql backend, but it isn't clear what the problem is. Here's the text of the error message:

[02-Feb-2010 03:45:02] Error at sapphire/core/model/DataObject.php line 2520: DataObjects have been requested before the database is ready. Please ensure your database connection details are correct, your database has been built, and that you are not trying to query the database in _config.php. (http://localhost:8888/silverstripe-v2.3.5/dev/build?flush=1)

Here's the contents of _config.php:

<?php

global $project;
$project = 'mysite';

global $databaseConfig;
$databaseConfig = array(
"type" => "MySQLDatabase",
"server" => "localhost",
"username" => "root",
"password" => "root",
"database" => "SS_mysite",
);

// Sites running on the following servers will be
// run in development mode. See
// http://doc.silverstripe.com/doku.php?id=devmode
// for a description of what dev mode does.
Director::set_dev_servers(array(
'localhost',
'127.0.0.1',
));

// This line set's the current theme. More themes can be
// downloaded from http://www.silverstripe.com/themes/
//SSViewer::set_theme('blackcandy');
SSViewer::set_theme('tutorial');

Debug::log_errors_to("silverstripe.log");

?>

When I look at the phpMyAdmin processes tab, I can see that there is a connection to the mysql listener, bound to the SS_mysite database. I can also use Sequel Pro to connect to localhost port 8889 as root/root and I go right into the database with no issues. Neither the apache nor the mysql logs give any errors.

Looking at the contructor for MySQLDatabase, I would have expected a "Couldn't connect to MySQL Database" for a basic connection error. After looking at the source code, its especially weird because the phpMyAdmin says that there's a db connection and it has selected SS_mysite, but then DB::globalconn->active should be true since it is set when the mysql_select_db selects SS_mysite.

Does anyone have an idea what might be the cause? Did the pear upgrade break something?

Thanks,
Steve

ps.
I started putting some debug statements into the code, and it looks like databaseConfig['database'] is set to "tmpdb4075729" which _doesn't_ exist. Though I see that there is a tmpdb6855694 laying around with 99 tables in it.

Avatar
Hamish

Community Member, 712 Posts

3 February 2010 at 3:26pm

that error is usually caused by trying to view the site before building your database - although i'm not sure how that impacts on test runners.

try building anyway by running /dev/build?flush=1

note that silverstripe creates temporary models (databases) to run tests on, so it is expected that the database doesn't exist.

Also, for easier debugging, turn on dev mode (see the wiki)

Avatar
sychan

Community Member, 5 Posts

3 February 2010 at 7:39pm

Hamish,
Thanks for the reply - turning on dev mode was very useful. I still was not able to run anything like a /dev/build?flush though.
But after putting in some debug calls and being able to see all the debug into, I was able to figure out that the $_SESSION variable contained an alternativeDatabaseName field that was overriding the settings in _config.php. Reading through the Session comments, it looks like this may have been set when I tried to run the unit tests. Restarting the browser cleared the session data and things are working again.

Thanks for the tip!
Steve