Mike Fuller's List: Software Development - Frameworks

• Doctrine implements a highly flexible pager package, allowing you to not only split listing in pages, but also enabling you to control the layout of page links.
• If you want to know that actual status of the pager, all you have to do is to check if it's already executed
• If you try to access any of the methods provided by Doctrine_Pager now, you'll experience Doctrine_Pager_Exception thrown, reporting you that Pager was not yet executed. When executed, Doctrine_Pager offer you powerful methods to retrieve information.
• To enable a more powerful control over pager, there is a small subset of pager package that allows you to create ranges.
• To abstract the business logic involving the page links generation, there is a powerful component called Doctrine_Pager_Layout. The main idea of this component is to abstract php logic and only leave HTML to be defined by Doctrine developer.
• Doctrine offers the ability to create and drop your databases from your defined Doctrine connections.
• The Doctrine Cli is a collection of tasks that help you with your day to do development and testing with your Doctrine implementation. Typically with the examples in this manual, you setup php scripts to perform whatever tasks you may need. This Cli tool is aimed at providing an out of the box solution for those tasks.

5 more annotations...

• The Doctrine migration package allows you to easily update your production databases through a nice programmatic interface. The changes are done in a way so that your database is versioned and you can walk backwards and forwards through the database versions.
• Transactions in Migrations
   Internally Doctrine does not wrap migration versions in transactions. It is up to you as the developer to handle exceptions and transactions in your migration classes. Remember though, that very few databases support transactional DDL. So on most databases, even if you wrap the migrations in a transaction, any DDL statements like create, alter, drop, rename, etc., will take effect anyway.

  • MySql DDL is NOT transactional
• The name of the class can be whatever you want, but the name of the file which contains the class must have a prefix containing a number that is used for loading the migrations in the correct order.
• Some DBMS like sqlite do not implement the rename column operation. An exception is thrown if you try and rename a column when using a sqlite connection.
• Sometimes you may perform some operations in the up() method that cannot be reversed. For example if you remove a column from a table. In this case you need to throw a new Doctrine_Migration_IrreversibleMigrationException exception.
• Sometimes you may need to alter the data in the database with your models. Since you may create a table or make a change, you have to do the data altering after the up() or down() method is processed. We have hooks in place for this named preUp(), postUp(), preDown(), and postDown(). Define these methods and they will be triggered:
• In Doctrine migrations it is possible most of the time to automate the opposite of a migration method. For example if you create a new column in the up of a migration, we should be able to easily automate the down since all we need to do is remove the column that was created. This is possible by using the migrate() function for both the up and down.
• Now when we run up with the above migration, the column will be added and when we run down the column will be removed.
• Doctrine offers the ability to generate migration classes a few different ways. You can generate a set of migrations to re-create an existing database, or generate migration classes to create a database for an existing set of models. You can even generate migrations from differences between two sets of schema information.

• Sometimes you may want to alter your models and be able to automate the migration process for your changes. In the past you would have to write the migration classes manually for your changes. Now with the diff tool you can make your changes then generate the migration classes for the changes.

    

  The diff tool is simple to use. It accepts a "from" and a "to" and they can be one of the following:

    

   
  • Path to yaml schema files
   
  • Name of an existing database connection
   
  • Path to an existing set of models

8 more annotations...

• In Doctrine all operations are wrapped in transactions by default. There are some things that should be noticed about how Doctrine works internally:
• • Doctrine uses application level transaction nesting.
   
  • Doctrine always executes INSERT / UPDATE / DELETE queries at the end of transaction (when the outermost commit is called). The operations are performed in the following order: all inserts, all updates and last all deletes. Doctrine knows how to optimize the deletes so that delete operations of the same component are gathered in one query.
• The Doctrine_Transaction::rollback($savepoint) rolls back a transaction to the named savepoint. Modifications that the current transaction made to rows after the savepoint was set are undone in the rollback.
• Mysql, for example, does not release the row locks that were stored in memory after the savepoint.

  • Based on previous statement, I assume Doctrine will remove mysql row locks.

• Savepoints that were set at a later time than the named savepoint are deleted.

    

  The Doctrine_Transaction::commit($savepoint) removes the named savepoint from the set of savepoints of the current transaction.

    

  All savepoints of the current transaction are deleted if you execute a commit or if a rollback is being called without savepoint name parameter.

      

3 more annotations...

• Data fixtures are meant for loading small sets of test data through your models to populate your database with data to test against.
• If you want to append the imported data to the already existing data then you need to use the second argument of the loadData() function. If you don't specify the second argument as true then the data will be purged before importing.
• You can dump data to fixtures file in many different formats to help you get started with writing your data fixtures. You can dump your data fixtures to one big YAML file
• Or you can optionally dump all data to individual files.
• Writing a fixtures file for a nested set tree is slightly different from writing regular fixtures files.
• When writing data fixtures for the NestedSet you must either specify at least a children element of the first data block or specify NestedSet: true under the model which is a NestedSet in order for the data fixtures to be imported using the NestedSet api.
• If you don't use one of the above methods then it is up to you to manually specify the lft, rgt and level values for your nested set records.

5 more annotations...