[ZF3] refactor sql

[turrsis]

Main architecture issue - current SqlObjects includes SqlBuilders.
This is not good design, it's coupe two separate things together - Describing and Building Query, including:

• functionality of sql objects and their builders realized in the same class, which creates problems with modifiable classes, stability and support.
• multiple entry points to build sql strings
• not possible to use builders for Expression. As sample concat() function have different syntax for various DB
• not possible to build nested sql. As sample Insert::into('foo')->select(Select::from('bar')->limit(10)) not work for SqlServer

Solution:

• builders functionality moved to separate classes.
• added builders for Expressions
• one entry point Builder\Builder::getSqlString() and Builder\Builder::prepareStatement().

Additionally was changed:

• AbstractSqlBuilder::createSqlFromSpecificationAndParameters() - more readable and flexible specifications
• Expression parameters always return ExpressionParameter object
• objects, are used tables, always return TableSource or TableIdentifier
• optimized UnitTests, added tests for various platforms
• optimized builders for Select::limit() and Select::offset()
• move duplicates from MySql\Ddl\CreateTableBuilder and MySql\Ddl\AlterTableBuilder to Mysql\Ddl\Column\ColumnBuilder
• Sql\Insert - add multiple values
• Sql\Ddl\DropTable - add 'IF EXISTS'
• add Sql\Ddl\Sql oblect for DDL
• rename Sql\Join to Sql\Joins
• rename Sql\SqlInterface to Sql\SqlObjectInterface and Sql\PreparableSqlInterface to Sql\PreparableSqlObjectInterface

[weierophinney]

@turrsis Could you please:

• rebase against the current develop branch
• update/rewrite the Zend\Db\Sql chapter of the documentation to reflect the new usage

The latter, in particular, will help us better understand the impact on end-users, and, of course, will be necessary for us to release any changes!

Thanks!

[turrsis]

@weierophinney I'll do it, will require about a week

[weierophinney]

@turrsis No rush! And thanks in advance!

[turrsis]

@weierophinney rebase done, sorry for delay. Fix CS and documentation I will do at next week.

[turrsis]

@weierophinney Where I should change documentation - in master or in develop branch?

[turrsis]

@weierophinney rebase and documentation is done

[froschdesign]

This is not needed, because there is already a DDL Abstraction.
I think, this is enough. (separation of concerns)

[turrsis]

You are right, I will fix it.

[alextech]

@turrsis How much sense, if at all, does it make for me to continue working on #163 to fix PostgreSQL problems? It started as a small fix, but with lack of existing PostgreSQL decorator I had to make one. I fixed the index creation problem so far, and since there are long standing PgSQL DDL compatibility issues reported in general, I was going to expand on that decorator in attempts to make it as reliable as MySQL decorator.

But the more I look at your changelist, I notice you do not just change the builder architecture but also adding lots of proper database abstractions, which is great!! So I am wondering that it would not be appropriate to duplicate the effort and confuse the maintainers with conflicting PRs if you are are targeting that area as well, but its a little hard to tell what to do without a direction/plan of what is going into this refactor.

What are you thoughts? and thanks for the amazing work!

[turrsis]

@alextech Sometimes I rebase this branch to last. If you will write correct tests, and you PR will be acepted - I apply you PR to this PR.

[turrsis]

@weierophinney Can you help me - where I wrong with last commit ("add travis ZF3 tests") ?

[ezimuel]

Closing this PR since it's more than 1 year old.

[walberty]

@ezimuel Why was this pull request closed? It looks like a lot of work is sitting here, including incorporating change requests, and there are older PRs in the project that are still open. Did the author reach out and say they abandoned this approach? Or is something similar being more actively developed somewhere else? thx