iTopiaBlog

When you have this problem just go into your controler e.g. index.php and add the following line:

$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'test', true);
new sfDatabaseManager($configuration);

In Symfony the stylesheets and javascript files are defined in the view.yml. Sometimes the problem appears that the browsers cache these files, even if there where some changes in the last release without refreshing the new contents.

There is a common technique to instruct the browser to take the new file version: Browsers store different file versions for different GET paramters. So if you include a CSS file like this:

<script type="text/javascript" src="css/styles.css?v=21"></script>

and in the next version with a higher version number (v=22), the browser will use  (and cache) the newer version.

In our case we save the current version number (SVN) into the app.yml and we use this number as increasing GET-Parameter to force a cache refresh:

default:
  stylesheets: [styles.css?v=<?php echo sfConfig::get('app_revision'); ?>]

I had the problem, that symfony had no write permissons to create the cache files in the Windows Azure approot folder.

After some research I found out, that it is possible to allocate local storage where the role user has write permissions. The disadvantage though is, that the local storage is not persistent, that means, it will be reset after role upgrades, instance reimage or reboots. But for caching I don’t need a persistent storage.

To get it running you need the folowing settings:

ServiceDefinition.csdef

Define a local resource, in this case with the folder name “FileCacheStorage” and the size 1000MB:

<?xml version="1.0" encoding="UTF-8"?>
<ServiceDefinition name="MyWebRole" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole enableNativeCodeExecution="true" name="WebRole" vmsize="ExtraSmall">
    ...
    <LocalResources>
      <LocalStorage name="FileCacheStorage" sizeInMB="1000" />
    </LocalResources>
 </WebRole>
</ServiceDefinition>

ProjectConfiguration.class.php

Change the default symfony cache path within the “setup()” method:

    if(strpos($_SERVER['HTTP_HOST'], "127.0.0.1")===false)
    {
    	$azureFileCachePath = substr($_SERVER['TEMP'], 0, 3).'Resources\Directory\\'.$_SERVER['RoleDeploymentID'].'.WebRole.FileCacheStorage\\cache';
    	$azureFileLogPath   = substr($_SERVER['TEMP'], 0, 3).'Resources\Directory\\'.$_SERVER['RoleDeploymentID'].'.WebRole.FileLogStorage\\log';

		  // Replace default path with local azure storage path, defined in ServiceDefinition ("LocalStorage" = "FileCacheStorage"):
		  $this->setCacheDir($azureFileCachePath);
    }

Notice: When you are testing in your local dev environment the local storage path is completely different (more information here), so I decided to change the path only in the cloud env, because locally I have no write problems. To get the recent drive letter I take it from $_SERVER['TEMP'].

(For the symonfy logging I did it the same way.)

Special thanks to Taylor for his hints.

I hope this helps somebody

Links

• How to Configure Local Storage Resources
• Azure – Reading and Writing with LocalStorage

To get your SQL Azure DB running with Symony 1.4 and Doctrine 1.2.4 you need to make the following changes:

In databases.yml:

all:
  doctrine:
    class: sfDoctrineDatabase
    param:
      dsn:      odbc:DRIVER={SQL Server Native Client 10.0};Server=SERVER.database.windows.net;Database=DATABASE;Encrypt=yes;
      username: USERNAME@SERVER
      password: PASSWORD

In symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Import/Mssql.php I had to change:

    public function listTableColumns($table)
    {
        #$sql = 'EXEC sp_primary_keys_rowset @table_name = ' . $this->conn->quoteIdentifier($table, true);
        $sql = 'EXEC sp_pkeys @table_name = ' . $this->conn->quoteIdentifier($table, true);

And in symfony/lib/plugins/sfDoctrinePlugin/config/sfDoctrinePluginConfiguration.class.php deactivate the setting ATTR_AUTO_ACCESSOR_OVERRIDE:

   $manager->setAttribute(Doctrine_Core::ATTR_AUTO_ACCESSOR_OVERRIDE, false);

The changes inside the Doctrine Plugin are not clean, it should be an accrodingly extension, but it worked for my quick requirement to generate a schema out of the database.

EDIT:

For some reason I got again an error while trying to build the schema out of the SQL Azure database:

SQLSTATE[42000]: Syntax error or access violation: 156 [Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near the keyword ‘File’. (SQLExecute[156] at ext\pdo_odbc\odbc_stmt.c:254). Failing Query: “EXEC sp_pkeys @table_name = File”

and

SQLSTATE[42000]: Syntax error or access violation: 156 [Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near the keyword ‘File’. (SQLExecute[156] at ext\pdo_odbc\odbc_stmt.c:254). Failing Query: “EXEC sp_columns @table_name = File”

To solve the problem I need to modifie the change I did in

symfony/lib/plugins/sfDoctrinePlugin/lib/vendor/doctrine/Doctrine/Import/Mssql.php:

    public function listTableColumns($table)
    {
        #$sql = 'EXEC sp_primary_keys_rowset @table_name = ' . $this->conn->quoteIdentifier($table, true);
        $sql = 'EXEC sp_pkeys @table_name = ' . $this->conn->quoteIdentifier($table, false);
        ...
        #$sql     = 'EXEC sp_columns @table_name = ' . $this->conn->quoteIdentifier($table, true);
        $sql     = 'EXEC sp_columns @table_name = ' . $this->conn->quoteIdentifier($table, false);

I changed the 2nd quoteIdentifier parameter to “false“.

When you try to get symfony running (for instance with windowsazure4e) there will occur some problems with the deployed version.

I could solve the problems with these very important php.ini settings:

• Locate the “cgi.force_redirect” setting and remove the comment and set the value to “0“‘ (Note: 0 for IIS and 1 for Apache or iPlanet).
• Locate the “cgi.fix_pathinfo” setting and remove the comment. Leave the value as “1” (Note: cgi.fix_pathinfo provides full PATH_INFO/PATH_TRANSLATED support for CGI. Previously the behavior of PHP was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to ignore PATH_INFO. For more information on PATH_INFO, see the cgi specs. Setting this to 1 will cause PHP CGI to fix its paths to conform to the spec.).
• Locate the “fastcgi.impersonate” setting and remove the comment, leave the value as “1” (Note: FastCGI under IIS supports the ability to impersonate security tokens of the calling client. This allows IIS to define the security context that the request runs under.).
• Locate “extension_dir” and set it to “ext“.