Commits
-------
395f580 Rebuild resource files with genrb from ICU 4.2. as ICU 4.4 by default builds them in newer format. Also added all files necessary to build resources.dat with pkgdat because syntax for command is so cryptic
438581d Skip test if running as superuser as it will fail
Discussion
----------
Fixes failing tests
This one closes both the #2355 and #2356
Commits
-------
3f8e8c9 fixes a session max lifetime handling
3abb7f3 fixed some conflicts with garbage collection
a1888b2 added a dbal session storage
Discussion
----------
Dbal session storage
Adds a session storage based on Doctrine DBAL.
---------------------------------------------------------------------------
by lsmith77 at 2011/09/14 13:39:28 -0700
guess it would be nice to then provide a service inside the DoctrineBundle that reuses a global DoctrineDBAL connection, guess the connection to use would then need to be configured via the doctrine app config.
---------------------------------------------------------------------------
by schmittjoh at 2011/09/14 13:42:34 -0700
I haven't found a sane way to provide automatic configuration that's why I left this to the user to implement. It's also relatively easy:
```yml
services:
dbal_session_storage:
class: Symfony\Bridge\Doctrine\HttpFoundation\DbalSessionStorage
arguments: [@database_connection]
framework:
session: { storage_id: dbal_session_storage }
---------------------------------------------------------------------------
by stof at 2011/09/14 13:57:48 -0700
@lsmith77 There is an issue about reusing another DBAL connection: if the transaction is aborted by the ORM, the session could be aborted too as you cannot have 2 independent transactions AFAIK
---------------------------------------------------------------------------
by lsmith77 at 2011/09/14 13:59:57 -0700
not sure how this is relevant. i mean why does the transaction need to be left open? just begin, write, commit ..
---------------------------------------------------------------------------
by stof at 2011/09/14 14:02:39 -0700
and what if the transaction of the ORM is still opened (let's say you use SimpleThingsTransactionalBundle) ?
---------------------------------------------------------------------------
by lsmith77 at 2011/09/14 14:06:12 -0700
well thats a bit of an edge case imho. also i wonder if SimpleThingsTransactionalBundle shouldn't make sure that its transaction is closed before the session is written.
---------------------------------------------------------------------------
by schmittjoh at 2011/09/14 14:06:56 -0700
It closes them.
On Wed, Sep 14, 2011 at 11:06 PM, Lukas Kahwe Smith <
reply@reply.github.com>wrote:
> well thats a bit of an edge case imho. also i wonder if
> SimpleThingsTransactionalBundle shouldn't make sure that its transaction is
> closed before the session is written.
>
> --
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/2182#issuecomment-2098100
>
---------------------------------------------------------------------------
by stof at 2011/09/14 14:15:02 -0700
@schmittjoh Does it close them **before** writing the session ?
---------------------------------------------------------------------------
by schmittjoh at 2011/09/14 14:44:15 -0700
I think either commit, or rollback is called, but @beberlei can probably answer that better.
Anyway, it is not really related to this PR because it is up to the user which connection is used.
---------------------------------------------------------------------------
by stof at 2011/09/14 14:58:48 -0700
I know that one of them is called. But if they are called after the session is persisted to the DB, a rollback is an issue as it will rollback the session persistence as well.
The PR is indeed fine. What need to be changed is the doc about how to use it, to advocate using a separate connection instead of the default one (which is used in your example)
---------------------------------------------------------------------------
by schmittjoh at 2011/09/15 02:57:34 -0700
There is no doc yet, but lets see what @fabpot thinks of all of this first.
---------------------------------------------------------------------------
by fabpot at 2011/09/15 04:57:57 -0700
Any benefits over using the PDO session storage?
---------------------------------------------------------------------------
by lsmith77 at 2011/09/15 05:00:50 -0700
cleaner code, potentially better support for niche RDBMS, centralized logging and finally afaik DoctrineDBAL has emulation for nested transactions.
---------------------------------------------------------------------------
by schmittjoh at 2011/09/15 05:11:00 -0700
The benefits (for me) are:
- logging queries
- better interoperability with existing build processes (migrations)
- better database interoperability
- re-using existing connection (I don't have the problem that Stof mentioned above)
---------------------------------------------------------------------------
by beberlei at 2011/09/15 06:18:22 -0700
The nested transactions is the problem here as @stof already said. If you reuse the default connection and use nested transactions that fail then this will make your session not save. That is why the docs should recommend you create a second connection for a dbal based session storage, even if it is using the same database. The PDO session storage would be a second connection besides DBAL aswell.
I like the migrations/schema hook though to create the table automatically through schema commands.
---------------------------------------------------------------------------
by fabpot at 2011/09/15 10:45:31 -0700
ok, looks good to me. Can you add some documentation about its usage (like the possible keys for options)? Is it possible to add some tests too?
---------------------------------------------------------------------------
by jdreesen at 2011/09/22 06:34:11 -0700
why did you close this?
---------------------------------------------------------------------------
by schmittjoh at 2011/09/30 06:26:12 -0700
I can't put more time into this PR, however I'm using it for some time already, and there shouldn't be any major issues as it is basically copy/paste from the PDO session.
Commits
-------
5473d3b [Translation] Allow use of UTF-8 encoded catalogues into non-UTF-8 applications
deb6dea [Translation] Add failing tests to verify that UTF-8 lang files can't be used with another charset
Discussion
----------
Allow use of UTF-8 catalogues in non-UTF-8 applications
This is #2313 but targetting the master branch.
Bug fix: yes
Feature addition: ?:)
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
The problem I'm having is that, while porting an existing app, we are using UTF-8 everywhere to have a migration path ready, but the current application and DB is still in ISO-8859-1, which means translations containing accented chars are broken.
Also, we didn't hit the issue yet since we don't use forms much, but I imagine we would have similar issues with core translations for the validator which are all UTF-8 encoded.
Note that I explicitly suppressed this conversion in case your application is setup as UTF-8, to make sure most people are not affected by any slow down this introduces.
Commits
-------
9219cf9 [FrameworkBundle] Sync the Russian translations with the SizeLength constraint
Discussion
----------
[FrameworkBundle] Sync the Russian translations with the SizeLength const
Commits
-------
8404b35 Updated indonesian translations for trans-unit 47 and 48
Discussion
----------
Updated indonesian translations for trans-unit 47 and 48
Commits
-------
5419638 [HttpKernel] Show the actual directory needing to be created.
Discussion
----------
[HttpKernel] Show the actual directory needing to be created.
Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
before: Unable to create the logs directory (/home/symfony/root/app)
after: Unable to create the logs directory (/home/symfony/root/app/logs)
Commits
-------
ee0fe7a Added guessers for Size and SizeLength constraints
Discussion
----------
Added guessers for Size and SizeLength constraints
Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
---------------------------------------------------------------------------
by jalliot at 2011/09/30 13:40:37 -0700
BTW, I've noticed that some constraints currently don't have guessers in 2.0:
* ``False`` (which could be guessed as a checkbox)
* ``True`` (which could be guessed as a required checkbox)
* ``Choice`` (which could be guessed as a choice type with medium confidence and with the choice list being guessed as the list provided for the constraint)
Are there any reasons why this is not implemented in 2.0 or should I try to make a PR for it?
There is also the ``Collection`` case but I guess it would be too difficult for this one...
Commits
-------
f9b2be9 Added french translation for SizeLength and UserPassword constraints
Discussion
----------
Added french translation for SizeLength and UserPassword constraints
---------------------------------------------------------------------------
by fabpot at 2011/09/30 13:45:46 -0700
47 is already taken for "This value should be the user current password". Should be 48.
---------------------------------------------------------------------------
by jalliot at 2011/09/30 13:59:01 -0700
@fabpot Fixed and added translation for 47 as well.
Fabien Potencier
Miha Vrhovnik
Jordi Boggiano
Helmer Aaviksoo
Katsuhiro OGAWA
Marcin Chylek
Deni
Alif Rachmawadi
excelwebzone
Danny Berger
Arnout Boks
Jordan Alliot