Accessing remote server using Zend_Db_Table - php

My current system is using Zend Framework 1, and works very well with our local MySQL server. However, I now need to access another server for importing/exporting. I'm using a class extended from zend_db_table_abstract in order to query the necessary table.
class Model_Db_ExportData extends Zend_Db_Table_Abstract{
protected $_name;
protected $_schema;
}
I instantiate name and schema when I create the object
$export = new Model_Db_ExportData(array('name' => $this->exportTable, 'schema' => $this->db));
EDIT
From what I can gather, zend_db_table isn't the place to define the host, since it only affects tables. However, I'm still unable to figure out where I can define a host outside of configs.
EDIT
How do I specify a separate server from the one defined in my configs? Do I need to use custom configuration files for this code? The Zend_Db_Table_Abstract documentation wasn't very helpful, although it's quite large and I could have easily missed something. Any help is very much appreciated.

There are at least 2 possible ways to accomplish what you want:
Zend_Db_Adapter - check the examples there to see how to create an adapter with the remote server settings;
Zend_Config_Ini - create a file with the remote server settings and then call in your application.

Related

Laravel randomly connects to different database

I have no idea how to google this since I mostly get tutorials about setting up multiple database connections.
At the moment, completely at random, my Laravel application gives me back an error about SQL, that the table could not be found. Laravel connects in this case to an entitely different database for some reason.
I connect in my .env and config/database.php to database1. Suddenly, an SQL error appears reading
Cannot find table `database2`.`table` in field list.
User also gets logged out when this error occurs.
Might be of use if i include that:
I sometimes use a custom user provider and sometimes the Laravel user provider. It depends on the subdomain. Error occurs on both configurations.
I dynamically add other database connections to the config, but never one to "database2". Database2 is a completely different application.
A search through the source code does not find any match with "database2"
Has anyone come across this problem? And if yes, how do I solve this? Thanks in advance!
Basically any Laravel Eloquent Model at seemingly Random will behave as if it was set with the public $connection="database 2"; variable.
Have you defined a model to use a different connection maybe?
Following the Laravel docs, this lets you use a different connection for specific models.
namespace App;
use Illuminate\Database\Eloquent\Model;
class Flight extends Model
{
/**
* The connection name for the model.
*
* #var string
*/
protected $connection = 'connection-name';
}
One of the most common reason is because you are setting your Configuration in a dynamic way with variables, so the Cache gets cached with the wrong information in this case the default database connection.
Or you could be setting the configuration at runtime which also makes the Illuminate\Foundation\Console\ConfigCacheCommand.php to generate the wrong files.
Make sure your configurations are serializable. Try running the command.
php artisan cache:config

Should a base PHP database class create multiple connections?

I have written a data class for handling MySQL queries and then all other classes such as login, products extend this class to make use of the database. As a result, each page load creates 2 or more DB connections due to something similar to the following:
$login, parent::__construct(); // check login via db
$products, parent::__construct(); // fetch products from db
Is there a way around this such as adding some code in the constructor to verify whether an existing DB connection has already been established?
A fellow developer I work with writes in procedural style and simply uses a single global $_db object for all queries and, this seems a lot more efficient as it only creates 1 DB connection.
For many smaller applications, I make my database instance global to the whole application, along with configuration and other application-wide classes, such as logging. This is not necessarily the preferred method, as it couples code to expect things named certain ways, and could possibly cause conflicts down the road. However, for small utility applications it is convenient.
For anything larger, I usually utilize my DB from an ORM anyway, so it becomes a non issue.
Michael's example of creating a static class and how to use it helped resolve the problem.
https://stackoverflow.com/a/26981461/541091

Using codeigniter Models in another non-codeigniter project

I have 2 projects accessing the same DB. One is with CodeIgniter, the other is a home made mvc framework. I'd like to use the same Model layer.
Is it possible to access Codeigniter Models from another project?
I'm not exactly sure why you would want to be accessing the same DB from two different frameworks at the same time (sounds like a recipe for disaster), but in general, I would say, "no."
What you actually want is not the model itself, You actually want the active records class located in /system/database/DB_active_rec, as that's the most common usage.
That class extends CI_DB_driver
This class accepts the config parameter for the DB(connection information).
You then want to extract the drivers themselves being used for the specific database you're working, the drivers can found at /system/database/drivers.
CI->model simply loads the DB_active_rec, that's why you need to do $this->db->insert()
I've never did so myself, But I don't see any major dependencies in the files themselves. I might have missed something though

Dependency injection class - where to store configs

When using dependency injection for database handlers etc instead of singleton - where is it best to keep the configs I.e. Username password host etc. Keep inside the class, use a container class or use a static configs class or use a file?
I generally keep them in a file outside of the webroot.
External config file that returns an array is a quick solution:
config.php:
<?php
return array(
'database'=> array(
'host'=> 'localhost',
'dbname'=> 'name_of_db',
'username'=> 'myusername',
'password'=> 'mypassword',
),
);
test.php:
<?php
$config = include('config.php');
mysql_connect($config['database']['host'], $config['database']['username'], $config['database']['password']);
....
Ideally, store the config file in a directory that can be read by the anonymous web user (but not written).
This is difficult to get 'right' because it depends on the exact use-case. But here's what I did when I had a very similar problem.
I had setup a shared library system for a small number of websites. Initially, it provided just a database handler, but there was quickly added an ORM layer. Most of the growth after that was additional objects as one of the websites was rewritten away from direct SQL into object-based access. There was also a configuration library used to define how the objects and other elements in the shared library were collected together into 'modules' as well as default settings for things like database settings. It also supported loading a configuration file outside the code-tree, which was used to per-host settings.
Since the objects in the ORM layer had to configure themselves (there was a static call to do that as they were declared), it was trivial for it to be extended to request a particular database by name, too. Then it was a matter of making sure that all these database definitions were declared as well (and were overridable thanks to the generic configuration mechanism).
(It took a while, but when we did reach the point of having to split the database, it was very easy to point the relevant objects off to another database and everything just kept working.)
To answer your question, though: the configuration was split. Database hostnames, usernames and passwords were all named and defined in one place in the in-code configuration area. But they could be overridden on a per-host basis. Per object settings were where the objects were declared. And that was also where the database configurations were specified by name.

PHP language barrier design problem

Background
I need to design a set of utility classes that will ease out file system access to several types of remote services (Local, FTP, WebDAV, SVN, SSH), and I cannot seem to get a "perfect" design mostly because of a language barrier - I feel that every design path I have chosen was scraped because PHP did not have support for a specific feature.
I find this frustrating and I'm out of ideas.
Requirements
A base abstract class or interface for FileSystem which every other file system type inherits. The FileSystem class (and it's subclasses) are a 'driver' that implement basic FS operations such as 'move', 'remove', 'create' and so on.
Those driver operations should not be exposed to the class user, instead, FileSystem is also a factory that fetches file info records upon request.
A file is also based on an abstract class or interface File and Directory, which the implementors of a FileSystem subclass may or may not subclass. Users of a FileSystem class do not 'care' about the type of a File (SshFile and SvnFile should work the same).
The File (and Directory) class should be the one to talk to the file system driver that created it in some way without the user being able to do it manually through the FileSystem driver.
What I have tried
Naturally I made FileSystem an abstract class, then proceeded to code the class File and turns out that PHP has no friend support, so File cannot have access to FileSystem's protected driver methods.
Another idea that got scraped was a class inside a class - FileSystem and FileSystem::File - PHP does not have nested classes.
Divide FileSystem into FileSystemDriver and FileSystemFactory, but that gets me into the same original problem.
300 Reputation points in bounty reward
To a solver of an original idea to PHP's lack of programming utilities needed for encapsulation.
Why can't you separate FileSystemDriver from FileSystem? For example:
class SSHFileSystem {
private $driver = new SSHDriver();
function getFile($path)
{
return new SSHFile($this->driver, $path);
}
}
Documentation problem, not code problem.
Leave the FileSystem's methods as public but document that they should only be used by internal File and Directory objects.
This is very common in languages. Python has magic methods, or the _function notation, etc.
If I'm a user, I don't just look at every available method and start using it if it sounds fun, I read the docs and do what they say.

Categories