Zend\Db\Metadata: Added AbstractSource, fully functional MysqlMetadata

[leftbrained]

The changes are listed below, they are mostly examples and are not fully propagated to the various classes, For instance, I haven't updated the MetadataInterface to reflect changes, nor updated other sources to reflect the changes in functionality.

If the changes are OK, I'll update to properly add the full functionality. I figured I'd let @ralphschindler take a look at this before I did any more.

Metadata\Metadata

• Updated MetadataInterface methods to pass through to source correctly.

Metadata\Source

• class AbstractSource
  Handles instantiation of Objects, while sub-classes are responsible for fetching of data.
• Reads schemas now (names only)
• Reads views, and base tables now (both inheriting from AbstractTableObject).
• Reads triggers now.

Metadata\Object

• Added numericUnsigned property to columns
• Added additional Errata setter/getter functionality
  Allows the storage of errata data in the AbstractSource->data property
• ConstraintObject->type
  Changed 'PRIMARY' to 'PRIMARY KEY' as that follows the standard
• Added ColumnObject->isNullable() alias for ColumnObject->getIsNullable()
• Added ColumnObject->isNumericUnsigned() alias for ColumnObject->getIsNumericUnsigned()

[leftbrained]

If I eliminate the fetch methods from AbstractSource, and let the sub-classes determine what leval to load at, that would probably be a good thing.

So AbstractSource would call loadSomething($schema, $table) , if a sub-class wants to run a query per-table or if they wanted to load all data in one query, they should be able to do so. And if AbstractSource doesn't keep track of what's been loaded, a sub-class could run a query every time. This might be good for SQLite, as it's getSchemas() function shouldn't be cached because it can change if they load a new file

[leftbrained]

PRs #1613, #1615, #1617 contain parts of this PR. When those are resolved, I'll rebase this one to master

[leftbrained]

A thought I had would be an Object structure, where each object is responsible for instantiating its descendants.

It would allow, say, a Schema object to be passed to a function, which would have all the components of that available to it.

The source would return assoc arrays, and would be passed down to each object during instantiation

A simplified example

<?php
class Metadata
{
    public function getSchema($schemaName)
    {
        $schema = new Schema($schemaName);
        return $schema;
    }
    // an ease-of-use function to get just a table name
    public function getTable($tableName, $schemaName)
    {
        return $this->getSchema($schemaName)->getTable($tableName);
    }
}
class Schema
{
    // This is the only place a Table ever gets instantiated
    public function getTable($tableName)
    {
        $options = $this->source->fetchTable($this->name, $tableName);
        return new Table($tableName, $options);
    }
}

[leftbrained]

I was going to extend AbstractSource from InformationSchemaMetadata, but realized I had no way to test Triggers. I only have SQLite, MySQL and PostgreSQL for testing purposes.

I tried cleaning up the code building the SQL in MysqlMetadata, but don't like the result. What do you think about using Select objects? We might do Select object in InformationSchema, but leave the platform specific ones unquoted (for readability).

[ralphschindler]

I don't see any value in using Select objects. Their purpose is primarily for SQL abstraction, which inside of our Metadata objects, we don't really care about. Once we write the right SQL, it likely will never need to change.

Lets chat on IRC