Let’s say you need to migrate old website to you new Symfony app. You want to keep all old links working. When they do not match the new link scheme, you want to redirect with 301 (or 302) to correct page in the new URL scheme. All these can be managed via backend module.

My first thought was I need a filter to catch sfError404Exception and handle redirections from there. Well, in Symfony 1.4 you can’t do it without changing the Symfony core files, so it’s not an option. This is because the filters are not even get called, as routing finds out first, that the module and/or action does not exists and throws this exception.

The solution:

There is the easier way of doing this. First you need to add new route that catches all that does not match current link scheme. In fact you need to replace default and default_index routes with something like this:

# apps/frontend/config/routing.yml
 
your_other_routes_here: ~
 
# generic rules
# please, remove them by adding more specific rules
# default_index:
#  url:   /:module
#  param: { action: index }
 
# default:
#  url:   /:module/:action/*
 
# at the very end of the file
catchall:
  url:   /*
  param: { module: default, action: catchall }

If you still need default and default_index routes you need to somehow handle forwards in your executeCatchall action. Please note that the above catchall route cannot be combined together with default and default_index. If you put catchall above these two, they won’t be executed ever, on the other hand – if you put it below these two, catchall will never be executed.

Then in this case you need to create executeCatchall action in your default module:

<?php
// apps/frontend/modules/default/actions/actions.class.php
class defaultActions extends sfActions
{
  public function executeCatchall(sfWebRequest $request)
  {
    // find your redirectation using $request->getPathInfo()
    $redirection = Doctrine_Core::getTable('Redirection')->findOneByPathInfo($request->getPathInfo());
 
    // this ensures that if there is no specified redirection, the old sfError404Exception gets thrown
    $this->forward404Unless($redirection); 
 
    // redirect
    $this->redirect($redirection['redirect_to']);
  }
}

In the above example I’m assuming the following model class:

Redirection:
  columns:
    path_info:        { type: string(255) }
    redirect_to:      { type: string(255) }

Of course this is very basic implementation of redirection functionality, but it shows the correct way of doing it. I hope it’ll help.

What’s wrong with handling sfError404Exception inside the execute404() action?

Well, it often happens that you need to throw sfError404Exception in your actions. It doesn’t feel right for me to throw this exception inside the method that handles it.

class UserForm extends Something
{
  public function configure()
  {
    $this->embedForm('entry', new EntryForm());
  }
}

and let’s say that this embedded form contains sfWidgetFormChoice widget

class EntryForm extends BaseEntryForm
{
  public function configure()
  {
    $this->widgetSchema['cars'] = new sfWidgetFormChoice(array(
      'choices' => array(),
      'expanded' => true
    ));
    $this->validatorSchema['cars'] = new sfValidatorChoice(array(
      'choices' => array()
    ));
  }
}

Mind that choices option is an empty array – I want to set this option in the action as it depends on data in the session.

I found that, the following code in the action layer doesn’t work:

class defaultActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
    $this->form = new UserForm();
    $this->form->getEmbeddedForm('entry')->getWidget('cars')->setOption('choices', $this->getUser()->getAttribute('cars'));
  }
}

Not sure why, but it’d work if the cars widget is attached to the UserForm. Maybe it’s related to this bug. Anyway, if try to set option choices, it sets correctly, but the view layer ignores it.

class defaultActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
    $this->form = new UserForm();
    $this->form->getEmbeddedForm('entry')->getWidget('cars')->setOption('choices',$this->getUser()->getAttribute('cars'));
 
    if($this->form->getEmbeddedForm('entry')->getWidget('cars')->getOption('choices') == $this->getUser()->getAttribute('cars'))
    {
      throw new Exception('setting up options for embedded forms works correctly, but the view layer seems to ignore it.');
    }
  }
}

So, if you have trouble setting up the dynamic options for the embedded form, you can do this, which seems to work.

class defaultActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
    $this->form = new UserForm();
    $this->form['entry']['cars']->getWidget()->setOption('choices', $this->getUser()->getAttribute('cars'));
  }
}

Same problem is with validatorSchema. I found that this seems to work:

class defaultActions extends sfActions
{
  public function executeIndex(sfWebRequest $request)
  {
    $this->form = new UserForm();
    $this->form['entry']['cars']->getWidget()->setOption('choices', $this->getUser()->getAttribute('cars'));
 
    // validator part
    $validatorSchema = $this->form->getValidatorSchema();
    $validatorSchema['entry']['cars']->setOption('choices',array_keys($this->getUser()->getAttribute('cars')));
  }
}

I hope it’ll help.

gentoo1 ~# ls -l /usr/bin/ | grep kvm
-rwxr-xr-x 1 root root      66872 May 28 16:03 kvm.kss

Luckily for me I do have more Gentoo machines with KVM virtualization.

I’ve logged in on my other KVM Gentoo machine and found out following:

gentoo2 ~# ls -l /usr/bin/ | grep kvm
lrwxrwxrwx 1 root root         17 Nov 11  2010 kvm -> /usr/bin/qemu-kvm
-rwxr-xr-x 1 root root         61 Nov 11  2010 qemu-kvm

OK – so what’s the content of the qemu-kvm file?

gentoo2 ~# cat /usr/bin/qemu-kvm
#!/bin/sh
exec /usr/bin/qemu-system-x86_64 --enable-kvm "$@"

From the above you can easily fix the problem by creating qemu-kvm file with content above, plus adding the kvm symlink. Hope it’ll help.

FROM_UNIXTIME()

MySQL query:

mysql> SELECT FROM_UNIXTIME(123456789);

PostgreSQL equivalent:

postgres=> SELECT to_timestamp(123456789); -- with time zone
postgres=> SELECT to_timestamp(123456789)::TIMESTAMP; -- without time zone

In order to be able to run MySQL style query in PostgreSQL DBMS, you need to create this function:

CREATE OR REPLACE FUNCTION from_unixtime(INTEGER) RETURNS TIMESTAMP AS '
	 SELECT to_timestamp($1)::timestamp AS result
' LANGUAGE 'SQL';

then you can run query like this (exactly the same as in MySQL):

postgres=> SELECT FROM_UNIXTIME(123456789);
    from_unixtime
---------------------
 1973-11-29 21:33:09
(1 ROW)

You can probably find (on the Internet) definitions with keyword abstime (i.e. $1::abstime::timestamp without time zone AS result).
This keyword is obsolete as described here, so IMHO it’s better to use the definition you see above.

UNIX_TIMESTAMP()

MySQL queries:

mysql> SELECT UNIX_TIMESTAMP();
mysql> SELECT UNIX_TIMESTAMP('1973-11-29 21:33:09');

PostgreSQL equivalents:

postgres=> SELECT EXTRACT(EPOCH FROM CURRENT_TIMESTAMP(0));
postgres=> SELECT EXTRACT(EPOCH FROM TIMESTAMP '1973-11-29 21:33:09');

Again – in order to be able to run MySQL style query in PostgreSQL DBMS, you need to create 3 functions:

-- no params
CREATE OR REPLACE FUNCTION unix_timestamp() RETURNS BIGINT AS '
	SELECT EXTRACT(EPOCH FROM CURRENT_TIMESTAMP(0))::bigint AS result;
' LANGUAGE 'SQL';
 
-- timestamp without time zone (i.e. 1973-11-29 21:33:09)
CREATE OR REPLACE FUNCTION unix_timestamp(TIMESTAMP) RETURNS BIGINT AS '
	SELECT EXTRACT(EPOCH FROM $1)::bigint AS result;
' LANGUAGE 'SQL';
 
-- timestamp with time zone (i.e. 1973-11-29 21:33:09+01)
CREATE OR REPLACE FUNCTION unix_timestamp(TIMESTAMP WITH TIME zone) RETURNS BIGINT AS '
	SELECT EXTRACT(EPOCH FROM $1)::bigint AS result;
' LANGUAGE 'SQL';

As noted here, prior to PostgreSQL 7.3, writing just timestamp was equivalent to timestamp with time zone. This was changed for SQL compliance.

Now you can run queries like this:

postgres=> SELECT UNIX_TIMESTAMP();
postgres=> SELECT UNIX_TIMESTAMP('1973-11-29 21:33:09');
postgres=> SELECT UNIX_TIMESTAMP('1973-11-29 21:33:09' AT TIME ZONE 'GMT');
postgres=> SELECT UNIX_TIMESTAMP('1973-11-29 21:33:09+01');

Tested on: PostgreSQL 8.1.11 (debian), PostgreSQL 8.2.7 (gentoo) and MySQL 5.0.70 (gentoo)

My live database, which I’ve used for this test contains 92298 valid email addresses, verified with the Pear Validate class with domain checking.

1
2
3
4
5
6
7
8
9
10

if(Validate::email($email,true))
{
    // add to database
    return true;
}
else
{
    // return error
    return false;
}

It means, if the email address is in this database – it is real and correct, otherwise the field is empty. So to make sure not to include empty fields, I’ve issued following query:

SELECT COUNT(*), LENGTH(email) AS SIZE FROM customer WHERE email LIKE '%@%' GROUP BY SIZE ORDER BY SIZE;

This query returns set of values, which I’ve used to create this chart (with OpenOffice.org Calc).

As you can see majority of email addresses are around 13 to 34 characters long. To store email addresses I’ve used VARCHAR (255) but as you can see VARCHAR(50) is enough.

The answer: VARCHAR(50) should do.