Commits
-------
1b5ad17 Revert "Removed MySQL-exclusive usage of unsigned integer from table creation"
Discussion
----------
[Security][DBAL] Revert MySQL unsigned removal
Revert "Removed MySQL-exclusive usage of unsigned integer from table creation"
This reverts commit 57694aaa94.
The problem is underlying in Doctrine DBAL change tracking and should
either be fixed or ignored there.
I opened a ticket on Doctrine Jira http://doctrine-project.org/jira/browse/DBAL-322
---------------------------------------------------------------------------
by fabpot at 2012-08-14T06:40:47Z
I will merge this PR after we have a release of DBAL that includes the fix for DBAL-322.
---------------------------------------------------------------------------
by acasademont at 2012-08-20T08:01:48Z
This was already fixed 2 weeks ago in doctrine/dbal#183 so i guess this can be closed
---------------------------------------------------------------------------
by acasademont at 2012-08-20T08:02:06Z
merged i mean
Commits
-------
3036b00 JsonResponseTest
Discussion
----------
JsonResponseTest
Hi,
This patch adds some tests for JsonResponse.
Best regards,
Michal
---------------------------------------------------------------------------
by eventhorizonpl at 2012-09-01T07:09:12Z
Done. Thanks for the review!
Commits
-------
8a3c8c9 load test
Discussion
----------
load test
Hi,
This patch add test that covers this situation
public static function load($classes, $cacheDir, $name, $autoReload, $adaptive = false, $extension = '.php')
{
// each $name can only be loaded once per PHP process
if (isset(self::$loaded[$name])) {
return;
}
Best regards,
Michal
Commits
-------
0af8778 Response tests
Discussion
----------
Response tests
Hi,
This patch adds some tests to ResponseTest.
Best regards,
Michal
---------------------------------------------------------------------------
by eventhorizonpl at 2012-09-01T09:45:16Z
Fixed, thanks for the review.
---------------------------------------------------------------------------
by eventhorizonpl at 2012-09-02T19:39:26Z
CS fixed. Thanks for the review :)
Commits
-------
c74d9a9 ResponseHeaderBag tests
Discussion
----------
ResponseHeaderBag tests
Hi,
This patch adds some ResponseHeaderBag tests. Now ResponseHeaderBag got 100% test coverage :)
Best regards,
Michal
Commits
-------
b89d4ee StreamedResponseTest
Discussion
----------
StreamedResponseTest
Hi,
This patch adds one test to StreamedResponseTest and fixes another. StreamedResponse has 100% test coverage.
Best regards,
Michal
Commits
-------
21a5841 RedirectResponse tests
Discussion
----------
RedirectResponse tests
Hi,
This patch adds 100% test coverage for RedirectResponse class.
Best regards,
Michal
Commits
-------
04fd5f1 [Form] Fixed PropertyPath to not modify Collection instances (not even their clones)
Discussion
----------
[Form] Fixed PropertyPath to not modify Collection instances
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: #4670
Todo: -
---------------------------------------------------------------------------
by pocallaghan at 2012-08-31T14:20:52Z
As far as I can see the pull request does fix the issue, which makes sense based on the code change (I didn't know iterator_to_array existed, good call). One thing I would say, I'm not sure on the use in the change to the test case. It's not clear to me what additional protection this extra assertion gives, as both the old and new code seem to pass.
---------------------------------------------------------------------------
by bschussek at 2012-08-31T14:21:46Z
The new assertion is there because not even the old code (`clone`) was tested.
---------------------------------------------------------------------------
by stof at 2012-08-31T14:37:38Z
@bschussek but was it failing without the code change ?
---------------------------------------------------------------------------
by bschussek at 2012-08-31T22:12:00Z
@stof It was not, but I was unable to write a good test for the change within reasonable time. I added an explanatory comment instead.
They are part of the public API (as const are always public) but cannot be used at all from outside the class as the $pluralMap is private. The meaning of the indices is already documented in the array.
Commits
-------
7ef6295 Removed the unnecessary file include
Discussion
----------
Removed the unnecessary file include
As of Doctrine 2.2, the ORM annotations can be found by the autoloader directly.
This will also avoid breaking the testsuite in case the dev deps have not been installed as the ORM would not be available in this case (the tests relying on the ORM should already be skipped when it is not available). See #5402
Commits
-------
cb7e3f5 [Routing] added route compile check to identify a default value of a required variable that does not match the requirement
Discussion
----------
[Routing] added route compile check to identify a bad default value
BC break: yes but only for strange route definitions
See the exception message in code for the reasoning.
An exception is thrown for a __required__ variable that __has a default__ that __doesn't match__ the requirement.
So optional variables can of course still have a default that don't meet the requirement, which is useful.
This helps to identify useless route definitions at compile time instead of when generating or matching a URL.
Commits
-------
890aea2 FileLocatorInterface used in typehint instead of FileLocator
Discussion
----------
FileLocatorInterface used in typehint instead of FileLocator
---------------------------------------------------------------------------
by stof at 2012-08-30T22:09:39Z
@fabpot this makes sense (and it is BC)
---------------------------------------------------------------------------
by mvrhov at 2012-08-31T08:34:17Z
What's wrong with Interface hint? I always hint interface when available as this means that I can inject whatever class implementing that interface.
Commits
-------
3363832 extended phpdoc of ConfigurableRequirementsInterface
5f64503 [Routing] added test for disabled requirements check
4225869 [Routing] allow disabling the requirements check on URL generation
Discussion
----------
[Routing] allow disabling the requirements check on URL generation
This adds the possibility to disable the requirements check (`strict_requirements = null`) on URL generation.
To sum up, here the possibilities:
- `strict_requirements = true`: throw exception for mismatching requirements (most useful in development environment).
- `strict_requirements = false`: don't throw exception but return null as URL for mismatching requirements and log it (useful when you cannot control all params because they come from third party libs or something but don't want to have a 404 in production environment. it logs the mismatch so you can review it).
- `strict_requirements = null`: Return the URL with the given parameters without checking the requirements at all. When generating an URL you should either trust your params or you validated them beforehand because otherwise it would break your link anyway (just as with strict_requirements=false). So in production environment you should know that params allways pass the requirements. Thus you could disable the check on each URL generation for performance reasons. If you have 300 links on a page and each URL at least one param you safe 300 unneeded `preg_match` calls. I tested the performance in one of my projects. The rendering time of a single template that contains ~300 links with several params was reduced from avg. 46ms to avg. 42ms. That are 8.7% reduction in the twig layer where the links are created on each request. So this option combines the improved usability of strict_requirements=false with an additional increased performance.
---------------------------------------------------------------------------
by fabpot at 2012-08-30T13:40:38Z
Can you put the comment about all the possibilities you have mentioned here in the phpdoc for future reference? Thanks.
---------------------------------------------------------------------------
by Tobion at 2012-08-30T13:49:25Z
In `ConfigurableRequirementsInterface` or which phpdoc would you like to have it? Because `ConfigurableRequirementsInterface` already has it explained. But I can extend its description if thats what you mean.
---------------------------------------------------------------------------
by fabpot at 2012-08-30T13:50:40Z
The comment in the PR is more explicit and more detailed than the one in the interface. So, yes, basically, it would be great if you can move all the information in the interface phpdoc.
---------------------------------------------------------------------------
by Tobion at 2012-08-30T14:35:59Z
Done.