Codeigniter 2 to 3 version after upgrading, I get this error..
Why would that be?
An uncaught Exception was encountered
Type: Exception
Message: Configured database connection is persistent. Aborting.
Filename: /var/www/vhosts/xxx.com/app/system/libraries/Session/drivers/Session_database_driver.php
Line Number: 94
Backtrace:
File: /var/www/vhosts/xxx.com/app/application/core/MY_Controller.php
Line: 11
Function: __construct
File: /var/www/vhosts/xxx.com/app/application/core/MY_Controller.php
Line: 52
Function: __construct
File: /var/www/vhosts/xxx.com/app/application/controllers/Dashboard.php
Line: 7
Function: __construct
File: /var/www/vhosts/xxx.com/application/index.php
Line: 293
Function: require_once
I had the same issue, and found that it was just a matter of changing a setting:
Modify your database.php config file and turn 'pconnect' to false. As part of the CI 3 Framework, it would be part of this array:
$db['default'] = array(
'pconnect' => FALSE // This value
);
Or if your config file looks more like the CI 2 version:
$db['default']['pconnect'] = FALSE;
A bit of searching seems to suggest that the database doesn't like a persistent connection, possible because of security reasons.
Disable caching in database.php file, define caching folder in database.php by
'cachedir' => APPPATH.'cache/db/',
setting and only use
$this->db->cache_on();
command where you want your database query being cached.
Don't forget to use
$this->db->cache_off();
after select queries for unwanted cached results.
It seems like codeigniter 3.0 doesn't support sessions using database, when persistent is enabled.
form: http://www.codeigniter.com/user_guide/libraries/sessions.html?highlight=session#session-preferences
However, there are some conditions that must be met:
Only your default database connection (or the one that you access as
$this->db from your controllers) can be used. You must have the Query
Builder enabled. You can NOT use a persistent connection. You can NOT
use a connection with the cache_on setting enabled.
You need to ensure that FALSE goes out without quotes.If you use 'FALSE', the database driver will take that as a true boolean. The system expects you to use FALSE directly, without quotes. So, unset pconnect instead of using 'FALSE' in order to default to FALSE, or use FALSE as a value if you like to keep things ordered :)
* Persistent connection flag
*
* #var bool
*/
public $pconnect = FALSE;
Related
I need to modify the existing 'default' connection.
I tried to write it like this:-
ConnectionManager::config('default',$consoptions);
It gives an error telling me that we cannot reconfigure existing key "default".
Is there any way to achieve what I want?
The example shown in the CakePHP Cookbook is wrong and causes the error
Cannot reconfigure existing key "default"
You actually need to drop the default database connection configuration before replacing it with a new one.
In addition, the ConnectionManager::config() methos is deprecated in favour of ConnectionManager::setConfig()
This is a working example that modifies the default database connection:
use Cake\Datasource\ConnectionManager;
$dsn = 'mysql://root:password#localhost/my_database';
ConnectionManager::drop('default');
ConnectionManager::config('default', ['url' => $dsn]);
It gives an error telling me that we cannot reconfigure existing key "default" Is there any way to achieve what I want?
Drop the config then configure it again.
Spend some time checking the API, it's almost all there.
How do I pass extra connection options, like connect_timeout, keepalives, etc.. with DBAL?
Should it be passed as driverOptions or a pull request created for explicit support at Doctrine\DBAL\Driver\PDOPgSql\Driver ?
I tried passing via driverOptions => ['connect_timeout' => 1], but not sure whether these settings are effective. When I do that with plain pdo_connect call:
$connectionString = 'host=... connect_timeout=1 keepalives=1 keepalives_idle=2 keepalives_interval=1 keepalives_count=2'
$connection = pg_connect($connectionString);
I know that these settings are at least applied because if I misspell any of those extra parameters an exception is raised:
$connectionString = 'host=... connection_timeout=1'
$connection = pg_connect($connectionString);
PHP Warning: pg_connect(): Unable to connect to PostgreSQL server: invalid connection option "connection_timeout" in /troubleshoot/psql.php on line 18
And this exception is the way I check that this setting has been applied.
I do not get such error if I misspell configuration passed to DBAL though.
Apparently this is not supported at the moment. All the extra options should be explicitly added to the PDOPgSql/Driver.php.
I'm trying to use the Laravel Redis session driver,
Problem is - It seems to always assume usage of the "default" connection. Does anyone know if its possible to use a different connection ?
For example "session" ? So all my session would be on one server?
Also, whenever I don't have a "default" key in the redis array, i get exceptions all over the place. Must I declare a "default" connection ? What's wrong with having my own names?
e.g.
It doesn't look like there's an easy way of doing what you want. The Redis based session driver uses the Redis based cache driver:
http://laravel.com/api/source-class-Illuminate.Cache.RedisStore.html#5-155
Unfortunately that doesn't provide any way to specify which connection to use - it just uses the default connection:
http://laravel.com/api/source-class-Illuminate.Redis.Database.html#3-96
(magic method calls to the above class go straight to the default connection)
A possible way to get what you want might be to write your own class that extends RedisStore with a constructor that takes in a connection name and sets $this->redis to whatever Redis::connection($name) returns. You'd also need to figure out how to get the session handler to use your own cache driver though. I don't know how easy it would be or how you'd do that - it might be difficult to try and wire it all up.
There are a few ways to go about this:
I will outline why you were getting errors and how to fix this the simple way (incase someone else has the same issue):
open at vendor/laravel/framework/src/illuminate/Redis/Database.php
create a $name variable for your connection at the top of the class
class Database {
/**
* The host address of the database.
*
* #var array
*/
protected $clients;
protected $name;
change the connection function to expect your own 'default' fallback and 'set the name' of your current connection.
on the command method you will need to provide your 'new connection name' ($this->name) instead of the default one.
that's it!
now from anywhere in the application you can use the 'Redis' facade to access your connections just like this:
REDIS::CONNECTION('small');
REDIS::CONNECTION('large');
REDIS::CONNECTION('session');
REDIS::CONNECTION('etc');
Change the session driver in Config\session.php from native to redis
Here is a snippet of the code I got from some tutorial blog:
<?php
class PersonalBlogController extends AppController {
var $name = 'PersonalBlog';
var $uses = array('PersonalBlog');
function index(){
//ini_set('max_execution_time', 300);
debug($this->PersonalBlog->findAll());
//debug($this->PersonalBlog->find('all'));
}
}?>
I have seen some other cases in max time limit fatal error from other posts. But mine is probably the most disgusting. The fatal 30 secs time limit error keeps coming even after I change the max_execution_time variable in php.ini. Even after changing it to 60 or 300 seconds, the error message stays the same. It says 30 seconds time limit is exceeded.
I then followed alternative solution from a similar question, which is to do this instead:ini_set('max_execution_time', 300); (See my commented code above).
The error is gone. However what happens after that is this:
Warning (2): PDO::__construct(): [2002] A connection attempt failed because the connected party did not (trying to connect via tcp://localhost:3306) [CORE\cake\libs\model\datasources\dbo\dbo_mysql.php, line 155]
.....
.....blablabla...
Fatal error: Call to a member function getAttribute() on a non-object in C:\Server\www\myserver.dev\public_html\cakephp-cakephp-7fbf7a4\cake\libs\model\datasources\dbo\dbo_mysql.php on line 259
So I realized that I actually have two MySQL server installed. The newest one (5.5.11) is on port 3307 not on port 3306! That is why I then changed my driver setting in the dbo_mysql.php:
/**
* Base configuration settings for MySQL driver
*
* #var array
*/
protected $_baseConfig = array(
'persistent' => true,
'host' => 'localhost',
'login' => 'root',
'password' => 'mysqlpassword',
'database' => 'personal_blog',
'port' => '3307'
);
Every other setting is normal; I have the same database setting for app>config>database file as you can see here:
public $default = array(
'driver' => 'mysql',
'persistent' => false,
'host' => 'localhost',
'login' => 'root',
'password' => 'mysqlpassword',
'database' => 'personal_blog',
'port' => 3307,
'prefix' => '',
);
After those changes, the warning still appears...I really feel like I want to throw up right now
Any help would be appreciated.thx
You shouldn't have to edit the dbo_config to manage the port setting. All of those keys are available for use in the database.php file in your app/config/ folder.
You actually shouldn't have your personal defaults in the dbo file at all -- nothing you are doing should ever edit any core files.
Once you have your port setting in ONLY the database.php file and your dbo driver is back to the one that shipped with cake you should delete all of the files in /tmp/cache and set your debug > 0 in app/config/core.php
Refresh and if the error is still occurring we know that something is messed up at the php.ini / .htaccess or ini_set level. Try adjusting the value and then loading a view that contains
<?php
phpinfo( );
?>
and see if the max execution time setting is actually being read by the php interpreter. If it isn't you might want to try the ini set method or htaccess methods of playing with that value. Also make sure the php.ini you are editing is the right one ( the path to the ini should be in the php info dump ) - you might find you have 2 versions of php loaded as well as your two versions of mysql.
If that doesn't solve or at least pinpoint the issue then post back here and let us know.
I am using Kohana (v3) framework but I believe it's not tied to a particular framework.
What I have is basically an app with a front-end, where I want to use Kohana's native Kohana::shutdown_handler(), but I also have a part of the - RESTful API - where I don't want colourful and html-encoded exception reporting. I want a plain text reporting.
The way I thought it might work is to register another shutdown function in API's controller abstract class constructor, but then I realised register_shutdown_function() works differently to set_exception_handler() and instead of replacing it adds another function to the shutdown procedure. What's worse PHP doesn't allow "unregistering" shutdown functions and that's where my problem lies.
What to do, if you want to use another shutdown function instead of one already registered?
You can simply overload views/kohana/error by your custom view and set
/**
* Initialize Kohana, setting the default options.
*
* The following options are available:
*
* - string base_url path, and optionally domain, of your application NULL
* - string index_file name of your index file, usually "index.php" index.php
* - string charset internal character set used for input and output utf-8
* - string cache_dir set the internal cache directory APPPATH/cache
* - boolean errors enable or disable error handling TRUE
* - boolean profile enable or disable internal profiling TRUE
* - boolean caching enable or disable internal caching FALSE
*/
Kohana::init(array(
'base_url' => '/',
'errors' => FALSE,
));
The first thing that comes to mind would be to add your function before any other register_shutdown_function() calls and have it call any necessary shutdown functions and then call exit or die to immediately end the script without calling other shutdown functions.
To ensure your call is first, I would make a separate file for it and add it as php.ini's auto_prepend_file.
Call it a hack...maybe. Does it work? I'm 99% sure it should.