OptionsResolver#validateOptionTypes should check if option value exists before checking its type; added corresponding test

OptionsResolver#validateOptionsCompleteness would already have thrown exception if the option were required, so this should only affect something explicitly marked as optional
validateOptionTypes checking existence of key rather than value
StreamedResponse always sends a HTTP 1.1 response

SERVER_PROTOCOL is "Name and revision of the information protocol via which the page was requested; i.e. 'HTTP/1.0'"
[Validator] Updated Spanish translations
merged branch chx/master (PR #5175)

Commits
-------

b00ea41 StreamedResponse always sends a HTTP 1.1 response

Discussion
----------

StreamedResponse always sends a HTTP 1.1 response

SERVER_PROTOCOL is "Name and revision of the information protocol via which the page was requested; i.e. 'HTTP/1.0'". The condition was for 1.0 which is wrong.

Earlier I filed #5173

---------------------------------------------------------------------------

by travisbot at 2012-08-03T18:33:45Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2030496) (merged b00ea417 into be41ca35).

---------------------------------------------------------------------------

by chx at 2012-08-03T18:36:58Z

Seems to me that the Travis fails have absolutely nothing to do with my patch.
[HttpFoundation] fixed typo (refs #5175)
[HttpFoundation] fixed tests (refs #5175)
merged branch franmomu/patch-2 (PR #5177)

Commits
-------

981da1a [Validator] Updated Spanish translations

Discussion
----------

[Validator] Updated Spanish translations

---------------------------------------------------------------------------

by travisbot at 2012-08-03T23:06:26Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2032706) (merged 981da1a9 into be41ca35).
merged branch EvanK/master (PR #5132)

Commits
-------

aa890ae validateOptionTypes checking existence of key rather than value
c6a9638 OptionsResolver#validateOptionTypes should check if option value exists before checking its type; added corresponding test

Discussion
----------

[OptionsResolver] validateOptionTypes raises error for optional, nonexistant option values

The [`OptionsResolver#validateOptionTypes`](https://github.com/symfony/OptionsResolver/blob/master/OptionsResolver.php#L315) method should check if a given option value exists before trying to test its type:

```php
<?php
// Two optional 'one' and 'two' options that, if they exist, must be a string and int respectively
$resolver = new OptionsResolver();
$resolver->setOptional(array('one', 'two'))->setAllowedTypes(array('one' => 'string', 'two' => 'int'));

// Correctly fails as wrong type
$resolver->resolve(array('one' => 1, 'two' => 'alpha'));

// Correctly succeeds
$resolver->resolve(array('one' => 'alpha', 'two' => 1));

// Raises error "Undefined index: two", see OptionsResolver.php line 315
$resolver->resolve(array('one' => 'alpha'));
```

---------------------------------------------------------------------------

by travisbot at 2012-08-01T01:46:50Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2006049) (merged c6a9638a into b1618d21).

---------------------------------------------------------------------------

by ericclemmons at 2012-08-03T05:15:27Z

I hope this makes it in for the 2.1 release.  We have several types attempting to take advantage of the `OptionsResolver` component and want to help resolve this.

---------------------------------------------------------------------------

by stof at 2012-08-03T07:30:44Z

:+1:

---------------------------------------------------------------------------

by travisbot at 2012-08-03T17:25:12Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2030053) (merged aa890aed into b1618d21).
updated VERSION for 2.1.0-RC1
bumped Symfony version to 2.1.0-DEV
fixed merge
[Doctrine Bridge] Added a parameter ignoreNull on Unique entity to allow a nullable value on field. Added Test
[Validator] Updated Catalonian translations y fixed typos in Spanish
merged branch franmomu/master (PR #5183)

Commits
-------

3d5b1db [Validator] Updated Catalonian translations y fixed typos in Spanish

Discussion
----------

[Validator] Updated Catalonian translations and fixed typos in Spanish

---------------------------------------------------------------------------

by travisbot at 2012-08-05T10:34:55Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2039920) (merged 3d5b1dbf into c99f9d29).
[DoctrineBridge] Fixed the testsuite
update zh_CN translations of Form Component
merged branch stof/fix_tests (PR #5184)

Commits
-------

85187ec [DoctrineBridge] Fixed the testsuite

Discussion
----------

[DoctrineBridge] Fixed the testsuite

In the master branch, the handling of non-utf8 values is done by Monolog as the data are passed through the context.

---------------------------------------------------------------------------

by travisbot at 2012-08-05T12:52:26Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2040281) (merged 85187ec2 into 20d2e5a1).
merged branch modi/master (PR #5186)

Commits
-------

83269a4 update zh_CN translations of Form Component

Discussion
----------

update zh_CN translations of Form Component

---------------------------------------------------------------------------

by travisbot at 2012-08-06T01:45:01Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2044024) (merged 83269a46 into 20d2e5a1).
merged branch Garfield-fr/master (PR #5015)

Commits
-------

f1c4b8b [Doctrine Bridge] Added a parameter ignoreNull on Unique entity to allow a nullable value on field. Added Test

Discussion
----------

[Doctrine Bridge] Added parameter ignoreNull to accept a nullable value on field

In my last project, i use this syntax to test unicity on 2 fields, but it fail because the validator stop if value is null. I dropped the test on validator and my unicity work fine.

```
@UniqueEntity(fields={"username", "deletedAt"})
```

It's possible to add this PR on Bridge.

Thanks

Bertrand

---------------------------------------------------------------------------

by stof at 2012-07-23T08:14:19Z

This is wrong. RDBMS allow several null values in a unique column and this change will break it.

---------------------------------------------------------------------------

by henrikbjorn at 2012-07-23T08:17:08Z

@stof seems weird indeed it would return if any of the values are null. Makes sense to do a query where the field `IS NULL` or whatever the find method does.

---------------------------------------------------------------------------

by stof at 2012-07-23T08:18:50Z

@henrikbjorn if you do a query with IS NULL, the validator would force to have only 1 entity with a null field whereas it is not the behavior of the DB-level constraint.

---------------------------------------------------------------------------

by henrikbjorn at 2012-07-23T08:20:41Z

In this case i suspect that he wants to achieve a `WHERE username = "henrikbjorn" AND deletedAt IS NULL` which would be valid right? Currently it just returns if any of the fields are null and the validation is never done.

---------------------------------------------------------------------------

by bschussek at 2012-07-23T08:27:24Z

I suggest to make this configurable as the handling of NULL values in UNIQUE columns [differs between SQL implementations](http://forums.mysql.com/read.php?22,53591,53591#msg-53591).

---------------------------------------------------------------------------

by Garfield-fr at 2012-07-23T08:52:53Z

@stof What the correct solution to test my unicity with deletedAt == null ?

I use this definition: @ORM\Column(name="deleted_at", type="datetime", nullable=true)

---------------------------------------------------------------------------

by Garfield-fr at 2012-07-23T20:28:44Z

In my local repository, i added a new parameter "$authorizedNullField" on UniqueEntity.php and tested this on UniqueEntityValidator.php:

Code: https://gist.github.com/4122efbe569e3c2c95c0

What about that ?

Thanks for your help

---------------------------------------------------------------------------

by stof at 2012-07-23T20:45:30Z

yep, this would be good (except for the naming which seems weird)

---------------------------------------------------------------------------

by Garfield-fr at 2012-07-23T20:46:44Z

No problem to change this. I don't find a good name for this ?

---------------------------------------------------------------------------

by stof at 2012-07-23T20:47:57Z

what about ``allowMultipleNull`` (defaulting to ``true`` for BC) ?

---------------------------------------------------------------------------

by Garfield-fr at 2012-07-23T20:51:30Z

Why multiple ? This option is for one or many. what about `allowNullable` ?

---------------------------------------------------------------------------

by stof at 2012-07-23T20:52:44Z

@Garfield-fr the current behavior allows having multiple null values without failing to the unique constraint

---------------------------------------------------------------------------

by Garfield-fr at 2012-07-23T20:56:07Z

ok. I make `allowMultipleNull`.

It's ok with that: https://gist.github.com/cae8d43780c45a5011ed

Thanks

---------------------------------------------------------------------------

by bschussek at 2012-07-23T20:58:12Z

What about `uniqueNull` (`false` by default)? `ignoreNull` (`true` by default)? I find `allowMultipleNull` a bit cumbersome.

---------------------------------------------------------------------------

by stof at 2012-07-23T20:58:26Z

no it is not. You have an issue in the validator. You have an extra negation.

Please update your PR

---------------------------------------------------------------------------

by Garfield-fr at 2012-07-23T21:01:59Z

@stof `ignoreNull` is ok for you ?

---------------------------------------------------------------------------

by stof at 2012-07-23T21:10:24Z

yes

---------------------------------------------------------------------------

by fabpot at 2012-08-05T07:48:03Z

Is it mergeable now? Is yes, @Garfield-fr Can you squash your commits?

---------------------------------------------------------------------------

by travisbot at 2012-08-05T08:43:23Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2039523) (merged 19ae3cf9 into c20c1d18).

---------------------------------------------------------------------------

by stof at 2012-08-05T12:09:02Z

@Garfield-fr when squashing the commits, you need to force the push as you are rewriting the history. You should not have merged with your remote branch

---------------------------------------------------------------------------

by Garfield-fr at 2012-08-05T12:10:15Z

What's the right solution for resolve this ?

---------------------------------------------------------------------------

by stof at 2012-08-05T12:11:09Z

@Garfield-fr reset your local branch to the squashed commit and force the push

---------------------------------------------------------------------------

by Garfield-fr at 2012-08-05T12:14:09Z

@stof Thanks for your help

---------------------------------------------------------------------------

by travisbot at 2012-08-05T12:19:06Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2040210) (merged f1c4b8b4 into 20d2e5a1).