Relationship can save extra columns

Separates primary key from actual primary key

When the model has a custom $primary_key other than 'id', the framework incorrectly attributes the value returned by insert_id() to the field represented by $primary_key instead of the actual DB's primary key column.

E.g.:

CREATE TABLE `user_profiles` (
  `id` int(11) NOT NULL,
  `username` varchar(24) COLLATE latin1_general_cs NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_general_cs;

ALTER TABLE `user_profiles`
  ADD PRIMARY KEY (`id`),
  ADD UNIQUE KEY `username` (`username`);

class User extends ActiveRecord
{
  protected $table_name = 'user_profiles';
  protected $primary_key = 'username';
  protected $foreign_key_name = 'username';
}

$user = new User(array(
  'username' => 'brixton',
));
$user->_force_create = true;
$user->save();

// Note the value 24 returned by insert_id() is incorrectly assigned to the field 'username':
var_dump($user);
/*
=> object(User)#724 (5) {
  ["table_name":protected]=>
  string(6) "user_profiles"
  ["primary_key":protected]=>
  string(6) "username"
  ["foreign_key_name":protected]=>
  string(6) "username"
  ["values":"ActiveRecord":private]=>
  array(3) {
    ["username"]=>
    int(24)
  }
  ["_force_create"]=>
  bool(true)
}
*/

// Since $user->username is set to the value of insert_id(), we have to query it again:
$user->find_by_id('brixton');
var_dump($user);
/*
=> object(User)#724 (5) {
  ["table_name":protected]=>
  string(6) "user_profiles"
  ["primary_key":protected]=>
  string(6) "username"
  ["foreign_key_name":protected]=>
  string(6) "username"
  ["values":"ActiveRecord":private]=>
  array(5) {
    ["username"]=>
    string(7) "brixton"
    ["id"]=>
    string(2) "24"
  }
  ["_force_create"]=>
  bool(true)
}
*/

Also note that the value 24 is assigned as a string to the int(11) column 'id', while it should be cast to an integer. This should be addressed with a dedicated issue.

This is more an annoyance than a bug, as the implementor should honor the framework contract. When defining a custom value of $primary_key other than 'id', this should be reflected in the table constraints of the DB schema.

Captures actual primary key column, fixes static find() method

This commit refactors ActiveRecord to use a new static property primary_key_name that allows subclassers to specify the name of the primary key column other than 'id'. The class also detects the actual primary key if disagreeing with the declared one, and stores it into a dictionary actual_primary_key_names with the class name as key. Finally, the static find() method is refactored to actually look for the actual class receiving the method call, rendering the second argument unnecessary (and deprecated).

Fixes #9.

Fixes wrong test message

When the model has a custom $primary_key other than 'id', the framework incorrectly attributes the value returned by insert_id() to the field represented by $primary_key instead of the actual DB's column.

E.g.:

CREATE TABLE `user_profiles` (
  `id` int(11) NOT NULL,
  `username` varchar(24) COLLATE latin1_general_cs NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_general_cs;

ALTER TABLE `user_profiles`
  ADD PRIMARY KEY (`id`),
  ADD UNIQUE KEY `username` (`username`);

class User extends ActiveRecord
{
  protected $table_name = 'user_profiles';
  protected $primary_key = 'username';
  protected $foreign_key_name = 'username';
}

$user = new User(array(
  'username' => 'brixton',
));
$user->_force_create = true;
$user->save();

// Note the value 24 returned by insert_id() is incorrectly assigned to the field 'username':
var_dump($user);
/*
=> object(User)#724 (5) {
  ["table_name":protected]=>
  string(6) "user_profiles"
  ["primary_key":protected]=>
  string(6) "username"
  ["foreign_key_name":protected]=>
  string(6) "username"
  ["values":"ActiveRecord":private]=>
  array(3) {
    ["username"]=>
    int(24)
  }
  ["_force_create"]=>
  bool(true)
}
*/

// Since $user->username is set to the value of insert_id(), we have to query it again:
$user->find_by_id('brixton');
var_dump($user);
/*
=> object(User)#724 (5) {
  ["table_name":protected]=>
  string(6) "user_profiles"
  ["primary_key":protected]=>
  string(6) "username"
  ["foreign_key_name":protected]=>
  string(6) "username"
  ["values":"ActiveRecord":private]=>
  array(5) {
    ["username"]=>
    string(7) "brixton"
    ["id"]=>
    string(2) "24"
  }
  ["_force_create"]=>
  bool(true)
}
*/

Also note that the value 24 is assigned as a string to the int(11) column 'id', while it should be cast to an integer. This should be addressed with a dedicated issue.

This is more an annoyance than a bug, as the implementor should honor the framework contract. When defining a custom value of $primary_key other than 'id', this should be reflected in the table constraints of the DB schema.

The framework now assumes relationships to be resolved by class name instead:

$car = new Car();
$car->find_by_id(1);
$car->has_one(Engine::class);

$engine = new Engine();
$engine->find_by_id(1);
$engine->belongs_to(Car::class);

// These are what we want
$this->assertNotNull($car->engine, "Expecting Car instance to have an 'engine' field but found null");
$this->assertNotNull($car->engine->car, "Expecting Engine instance to have a 'car' field but found null");

$this->assertNotNull($engine->car, "Expecting Engine instance to have a 'car' field but found null");
$this->assertNotNull($engine->car->engine, "Expecting Car instance to have an 'engine' field but found null");

Additionally, a deprecation notice is issued when the caller tries to resolve a relationship via table name:

Deprecated: Car::has_one was invoked with a table name instead of a class name. This behavior 
is deprecated and will be removed in a future milestone. Please refactor your code to use class 
names. in <PROJECT_ROOT>/emeraldion/emerails/models/base.php on line 406

The ability to use custom table names affects the consistency of names of related objects in relationships.

E.g. if you have the following models:

class Car extends ActiveRecord
{
  protected $table_name = 'coches';
}

class Engine extends ActiveRecord
{
  protected $table_name = 'motores';
}

When fetching associated models, there are unexpected outcomes like this:

$car = new Car();
$car->find_by_id(1);
$car->has_one('engine'); // this is fine
var_dump($car->engine); // this is fine
var_dump($car->engine->car); // not fine, NULL
var_dump($car->engine->coche); // derived from $table_name, undesired

$engine = new Engine();
$engine->find_by_id(1);
$engine->belongs_to('car'); // this is fine
var_dump($engine->car); // this is fine
var_dump($engine->car->engine); // not fine, NULL
var_dump($engine->car->motore); // derived from $table_name, undesired, wrong singular

Deprecates relationship by table name, issues warning. Fixes #4

Sets composer archive ignore list

Disables object pool

Fixes wrong table name

Tests exception when saving incorrect one to many relationship

Relationship objects - first stab

Improves relationship resolvers

Ensures primary key is only saved when creating models

Fixes multiquery result fetch

Implements many-to-many relationship by class name

Implements has_one and belongs_to relationships by class name

Sets controller's base path in router

Supports namespaced model class names

Fixes for new config

Adds bin directory

Adds bin directory

Disambiguates constants

Reorganizes imports

Explicitly register DB adapters

Wraps more classes in PSR-4 modules

Implements DbAdapter::exec_multiline()

Ensures variable is global

Formatting

Improves imports

Switches to config provider

Convert to psr-4

Update dependencies