Commits
-------
0677ed7 [Validator] Updated Romanian translations
Discussion
----------
[Validator] Updated Romanian translations
Just a small update for the validator translation.
---------------------------------------------------------------------------
by travisbot at 2012-08-08T21:47:01Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2070722) (merged 0677ed77 into 7dbadbf2).
Commits
-------
33105e0 [Locale] added more information to the README.md regarding the need to build the ICU data when the intl extension ICU data version mismatch the one shipped with Symfony
3191c70 [Validator] fixed tests, ICU 4.4 (Travis version) does not have the "my" locale
d7b6bb3 [Locale] updated README.md
6456361 [Locale] added note about ICU data building: use the same PHP intl/ICU version as the desired version to build
025f972 [Locale] renamed function
8da99ca [Locale] updated CHANGELOG.md
d909360 [Locale] don't create a "current" directory anymore, uses only the ICU version as the name of the data directory
3f2b4bf [Locale] changed build data script name
61e3539 [Form][Locale] updated minimum ICU version to 4.0
0d442c7 [Locale] as of ICU 4.8+, slash ("/") and dash ("-") are interchangeable, you can use any of them in a date/time pattern
90d6dc3 [Locale] fixed tests
86da1b3 [Locale] added ICU update-data script to be run before the test suite
5fd4eb1 [Locale] updated ICU data paths
64ccee7 [Locale] updated ICU data
0d0a8d4 [Locale] updated script to generate separated data directories for different ICU releases
Discussion
----------
[2.1][Locale] ICU data update
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: no
Fixes the following tickets:
Todo: -
License of the code: MIT
[](http://travis-ci.org/eriksencosta/symfony)
The tests are passing in Travis only because it uses ICU 4.4. The tests fails in ICU 4.8 and 49.1. The data files now are up-to-date with ICU 49.1.2. The fails are consistent between 32 and 64 bit for the PHP 5.3.3, 5.3.14 and 5.4.4 (each one compiled with ICU 4.2 to 49).
Basically tests that relies on Locale will have some idiosyncrasies:
- Some tests will assert a different value for different ICU versions, mostly for currency/date formatting
- Some tests will skip if not the latest ICU release, code that format/parse something that is directly based on ICU behavior will always implement the behavior from the latest release
- Some tests will make different assertions for different PHP versions (we already have them, just to note)
The Composer script handler was a very quick implementation, I accept suggestions about it. It basically invokes the `update-data.php` script. I will also rename this script later since it now behave a little bit different from the original script.
@fabpot, @stof: should I add mine Composer `post-install-cmd` script in both the project root and component `composer.json` file?
I'm planning to configure a CI server with a setup similar with mine Symfony development environment to run jobs with the different PHP/ICU releases for the Locale component. But most importantly is to document how I did it since it took a lot of time to have an enviroment that supports all this "ICU hell development". Also, there are some pitfalls regarding testing and to generating the resource bundles for the different ICU versions.
Almost there! I'll try to update later tomorrow (monday).
---------------------------------------------------------------------------
by fabpot at 2012-07-30T08:14:29Z
I would not have added the script in the `composer.json` file but in the `.travis.yml` file directly instead. We don't want this script to be run whenever someone run composer on the repository.
---------------------------------------------------------------------------
by eriksencosta at 2012-07-31T03:07:58Z
Ok, moved the script call to the `.travis.yml` file.
---------------------------------------------------------------------------
by eriksencosta at 2012-07-31T12:38:23Z
@stof The last commit was just to backup WIP changes and to ask something to @igorw, it is mine "stage" :)
---------------------------------------------------------------------------
by travisbot at 2012-08-06T03:05:16Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2044244) (merged c6a1dcd1 into 20d2e5a1).
---------------------------------------------------------------------------
by travisbot at 2012-08-06T03:16:12Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2044311) (merged 76868419 into 20d2e5a1).
---------------------------------------------------------------------------
by travisbot at 2012-08-06T03:52:20Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2044425) (merged 7e768eb2 into 20d2e5a1).
---------------------------------------------------------------------------
by travisbot at 2012-08-06T04:04:30Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2044461) (merged edaca423 into 20d2e5a1).
---------------------------------------------------------------------------
by eriksencosta at 2012-08-06T04:33:55Z
Ready for primetime. The failed test is not related with mine changes.
---------------------------------------------------------------------------
by travisbot at 2012-08-07T02:32:19Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2053806) (merged 386d20c8 into 842b599c).
---------------------------------------------------------------------------
by fabpot at 2012-08-07T13:51:59Z
After merging this PR, I have more failing tests on my machine:
PHP 5.3.8 - ICU 4.4.1
Is it expected? Is yes, how do we need to run the tests locally?
---------------------------------------------------------------------------
by eriksencosta at 2012-08-07T14:56:23Z
@fabpot Yep, it is expected. You'll need to build the ICU data for this version and export the `USE_INTL_ICU_DATA_VERSION` before running the tests:
php src/Symfony/Component/Locale/Resources/data/build-data.php
export USE_INTL_ICU_DATA_VERSION=1
phpunit src/Symfony/Component/Locale/Tests
The errors happens because the implementation is in sync with the behavior of ICU 49.1.2 and the shipped data is from data version too. Maybe I should add the steps above in the components `README.md` since it is more straightforward.
---------------------------------------------------------------------------
by fabpot at 2012-08-07T14:58:44Z
@eriksencosta Yes, that would be good to add some more information in the README file.
---------------------------------------------------------------------------
by eriksencosta at 2012-08-07T15:21:04Z
@fabpot Done!
---------------------------------------------------------------------------
by eriksencosta at 2012-08-07T15:21:29Z
And rebased.
Commits
-------
3e1a1ab Force the value of Dumper::setIndentation($num) to be of type integer.
5be7237 Added Yaml\Dumper::setIndentation() method to allow a custom indentation level of nested nodes.
Discussion
----------
[Yaml] Allow custom indentation level for nested nodes
YAML does not specify an absolute indentation level, but a consistent indentation of nested nodes only: http://yaml.org/spec/current.html#indentation%20space/
Projects that are generally using 2 spaces for indentation should be able to retain consistency with their coding standards by supplying a custom value for the new $indent parameter for Yaml::dump() and Dumper::dump().
The new parameter is a backwards-compatible API addition and defaults to the previous default of 4 (which was changed from 2 via PR #2242 only recently).
The old $indent parameter is renamed to $level, and remains to be used internally only.
---------------------------------------------------------------------------
by travisbot at 2012-08-03T00:24:22Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2024289) (merged 56331202 into b1618d21).
---------------------------------------------------------------------------
by travisbot at 2012-08-03T00:29:02Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2024315) (merged eeae28a4 into b1618d21).
---------------------------------------------------------------------------
by travisbot at 2012-08-03T02:41:42Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2024905) (merged 9a82c438 into b1618d21).
---------------------------------------------------------------------------
by fabpot at 2012-08-03T07:53:50Z
This is indeed a BC break as the method signature changed in a non-BC way.
---------------------------------------------------------------------------
by fabpot at 2012-08-03T08:35:51Z
I think I would prefer to have a static method to be able to change the number of spaces to use on a global basis. It makes more sense and would prevent the BC break. What do you think?
---------------------------------------------------------------------------
by sun at 2012-08-03T13:23:23Z
Thanks for your feedback! — Took some time to think through the static proposal. Here's what I think:
1. The call from DependencyInjection\Dumper\YamlDumper truly was a unexpected/nasty surprise for me. That is, because it passes a parameter to Yaml\Dumper that is documented for internal use only, and the surrounding YamlDumper code generally hard-codes lots of assumptions of where exactly the nodes/collections will be output in the dumped YAML structure. (I think that code can be simplified, cleaned up, and made faster at the same time (hence the todo), but indeed, that probably belongs into a separate issue.)
1. The essential problem with a static is closely bound to that though; a static property value for the indentation would "stick" and thus hi-jack the DependencyInjection\Dumper\YamlDumper, as it hard-codes and thus expects 4 spaces (contrary to any custom indentation).
1. Most code uses Yaml\Yaml as utility/helper service directly, so there'd be no clean way to prime the static with a custom value, aside from subclassing the entire thing - in which case this entire issue would sorta become moot, because at the point you're subclassing, you can as well go the extra mile and replace the entire Yaml\Dumper::dump() to implant the custom indentation level...
1. Another option would be to use a non-static Yaml\Dumper::$indent property, supplied through the constructor; i.e.:
public function __construct($indent = 4)
...or alternatively, ::setIndentation(). Essentially requiring people to use and instantiate Yaml\Dumper directly, if they want to use a custom indentation.
1. Though in the end, I don't want to sound pedantic, but I *do* wonder a bit about the exact extent of the `@api` tags, as well as `@param`s that are explicitly documented as "internal use only"... :) That is, because only Yaml\Yaml is tagged with `@api`, but nothing in Yaml\Dumper. The same sorta applies to DependencyInjection\Dumper\YamlDumper::dump(), which is tagged with `@api`, but the :.addService() method being adjusted accordingly here is not. So essentially, when taking those tags (plus the param's description) seriously and in a nitpicky way, then there is no BC break, since no one should rely on their exact implementation... ;) (I perfectly realize that this is a long shot :))
So... depending on the final stance on the last point, I'd either move forward with the current proposal in this PR. Otherwise, I'd suggest the non-static property on Yaml\Dumper - in which case we'd likely try to swap out the static Symfony\Component\Yaml\Yaml helper with a Drupal\Component\Yaml\Yaml in order to always instantiate the dumper with the custom indentation. What do you think?
---------------------------------------------------------------------------
by sun at 2012-08-04T22:57:21Z
Alright. While I believe I made some good points in my last comment, I've taken the fully backwards-compatible path:
- added the new $indent parameter only to Yaml::dump()
- added a new Dumper::$intendation property and Dumper::setIndentation() method, to control the indentation level within the scope of a single Dumper instance only.
Do you think this is acceptible? :)
---------------------------------------------------------------------------
by travisbot at 2012-08-05T06:16:22Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2039120) (merged 5be7237b into c99f9d29).
---------------------------------------------------------------------------
by travisbot at 2012-08-07T07:51:04Z
This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2055164) (merged 3e1a1abd into c99f9d29).
---------------------------------------------------------------------------
by sun at 2012-08-07T07:53:18Z
Only one environment failed, and the [test failure](http://travis-ci.org/#!/symfony/symfony/jobs/2055165/L203) seems unrelated to this PR.
Commits
-------
c2207da [Console] Removed unused phpunit annotation.
c0c61da [Console] Added current style appliance for all styled text.
696a653 [Console] Removed text transformation for empty styles.
c7e324a [Console] Added test for non style tag formatting.
Discussion
----------
[Console] Non style tags dont disturb formatting anymore
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes issue #5196.
---------------------------------------------------------------------------
by travisbot at 2012-08-06T19:35:20Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2050455) (merged c0c61da0 into 842b599c).
---------------------------------------------------------------------------
by travisbot at 2012-08-07T07:47:31Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2055153) (merged c2207da6 into 842b599c).
Commits
-------
af0149d [Console] Added some precision in OutputInterface::write docblock.
Discussion
----------
[Console] Added some precision in OutputInterface::write docblock.
No code affected :)
Fixes issue #4947
---------------------------------------------------------------------------
by travisbot at 2012-08-06T19:50:02Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2050525) (merged af0149d6 into 842b599c).
Commits
-------
b3cf36a [Config] Missing type argument passed to loader.
Discussion
----------
[Config] Missing type argument passed to loader.
In FileLoader the $type is not passed to the child loader.
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
License of the code: MIT
---------------------------------------------------------------------------
by travisbot at 2012-08-06T14:22:30Z
This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2047982) (merged b3cf36af into 89dce2df).
Commits
-------
cdfbe72 handle inheritance in config:dump-reference when a bundle name is passed to the command
Discussion
----------
handle inheritance in config:dump-reference
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: ?
Fixes the following tickets: -
License of the code: MIT
Currently when passing in a bundle name that identifies a bundle that is a parent to another bundle, it will not return the reference for the requested bundle, but for the inheriting (even if that bundle has no configuration class).
F.e.
app/console config:dump-reference SymfonyCmfBlockBundle
will fail if there is a Bundle SandboxBlockBundle that has SymfonyCmfBlockBundle set as the parent.
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).
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).
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).
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).
YAML does not specify an absolute indentation level, but a consistent indentation of nested nodes only: http://www.yaml.org/spec/1.2/spec.html#space/indentation/
Projects that are generally using 2 spaces for indentation should be able to retain consistency with their coding standards by supplying a custom value for the new $indent parameter added to Yaml::dump(), or the new Dumper::setIndentation() method.
The new parameter is a backwards-compatible API addition and defaults to the previous default of 4 (which was changed from 2 via PR #2242 only recently).
Fabien Potencier
Florin Patan
Drak
Kris Wallsmith
Eriksen Costa
Grégoire Pineau
Bilal Amarni
sun
Jan Marek
jfsimon
hidenorigoto
Benjamin Eberlei
modi
Christophe Coevoet
Fran Moreno
Bertrand Zuchuat
Tobias Schultze
