Commits
-------
dc5772d use ORM master
4364463 use doctrine-common master
55b572d fixed getting the alias for a namespace
2b89e15 use getObjectNamespace() in getEntityNamespace()
0217a0e updated base class name
e8f3c21 updated vendors to point to lsmith77's fork of doctrine-common until its merged
6e87d01 fix tests
13c2f33 added a default implementation of the ManagerRegistry integrating the container
Discussion
----------
[Doctrine] added a default implementation of the ManagerRegistry
Bug fix: no
Feature addition: yes
Backwards compatibility break: yes (minor change in the interface see below)
Symfony2 tests pass: yes
Fixes the following tickets: -
added a default implementation of the ManagerRegistry integrating the container
attempted to maintain BC as good as possible, but RegistryInterface::getRepository() had to be dropped from RegistryInterface. Its still part of the ManagerRegistry, so its only a BC break for people using RegistryInterface to create their own implementation as I ran into https://bugs.php.net/bug.php?id=43200
all implementation (ORM/ODM) will need to match the changes to the ClassMetadataFactory interface
ORM, PHPCR, CouchDB have been upgraded already.
The Bundles also need to be updated. ORM is covered with this PR, I have a PR ready for PHPCR:
https://github.com/symfony-cmf/symfony-cmf/pull/108
also note that before merging the change to vendors.php needs to be fixed to point to the right repo again
For MongoDB it currently does not yet have a registry and I can take care of CouchDB once this is all merged.
---------------------------------------------------------------------------
by lsmith77 at 2011/09/23 00:40:07 -0700
still a few failing tests and details still need to be discussed ..
---------------------------------------------------------------------------
by lsmith77 at 2011/09/23 00:53:23 -0700
ok .. tests are passing now
---------------------------------------------------------------------------
by lsmith77 at 2011/10/11 10:27:52 -0700
ok Doctrine/ORM updates are done .. PR updated .. ready to be merged.
Without this, the exception is eventually thrown in EntityChoiceList::getIdentifierValues() with a very a message that doesn't really suit the real error: "Entities passed to the choice field must be managed"
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.
attempted to maintain BC as good as possible, but RegistryInterface::getRepository() had to be dropped from RegistryInterface. Its still part of the ManagerRegistry, so its only a BC break for people using RegistryInterface to create their own implementation
Commits
-------
d19f1d7 [Doctrine] Fix UniqueEntityValidator reporting a false positive by ignoring multiple query results
Discussion
----------
[Doctrine] Fix UniqueEntityValidator reporting a false positive by ignoring multiple query results
An entity should only be considered unique if its search criteria returns no matches or a single, identical entity. Multiple results indicates that conflicting entities exist.
Note: the DoctrineMongoDBBundle's unique validator checks identifier values if the object strict-equality check is false. This may be a worthwhile improvement, as it would prevent reporting a validation error for an enttiy which is going to overwrite its conflicting counter-part in the database.
---------------------------------------------------------------------------
by jmikola at 2011/09/01 14:23:27 -0700
This is the Doctrine bridge equivalent for my fix to DoctrineMongoDBBundle: https://github.com/symfony/DoctrineMongoDBBundle/pull/42
---------------------------------------------------------------------------
by fabpot at 2011/09/02 00:13:52 -0700
As this is a bug fix, can you base your PR on the symfony/2.0 branch? Thanks.
An entity should only be considered unique if its search criteria returns no matches or a single, identical entity. Multiple results indicates that conflicting entities exist.
Commits
-------
6bd1749 Fixed a bug when multiple expanded choices would render unchecked because of the Form Framework's strict type checking.
Discussion
----------
[DoctrineBridge] Entities to array transformer
Fixed a bug when multiple expanded choices would render unchecked because of the Form Framework's strict type checking.
---------------------------------------------------------------------------
by fabpot at 2011/08/31 09:01:47 -0700
Looks good to me. Can you squash your commits before I merge? Thanks.
* yethee/doctrine_bridge:
[DoctrineBridge] Removed all options of the parent type
[DoctrineBridge] Removed unneeded use statement
[DoctrineBridge] Fixed typo
[DoctrineBridge] Removed duplicating options in EntityType
* added a RegistryInterface
* changed all classes to depend on the Registry instead of a specific EntityManager
This is more consistent as the validator already took the registry and this allows
to use any entity manager in Forms.
* CodeMeme/889-EntityChoiceField-grouped-choices:
Whitespace cleanup
Fixed EntityChoiceList to support grouped entities Refs #889
Added test for grouped entity choice list Refs #889
* bschussek/form: (22 commits)
Fix merge error (function "guess" was in there twice)
[Form] Added test case for bf2f9d2a02
[Form] Form::isBound() and Form::isValid() work correctly now for read-only forms
[Locale] Improved error reporting and added stubs for intl_is_failure(), intl_get_error_code() and intl_get_error_message()
[Form] Implemented fix for 361c67f54f
[Form] Add test for the handling of array values in the constraint violation
[Form] Further simplified PropertyPath code
[Form] Added test for 6c337d1cc0
[Form] Removed unused option "pattern" of date and time type
[Form] Renamed view variable "name" to "full_name"
[Form] Renamed collection option "type_options" to "options" to be consistent with the repeated type
[Form] CSRF documentation and a few CS changes
[Form] Move CSRF options from types to the CSRF extension
[Form] Added a search form field type
[Form] Optimization of PropertyPath
[Form] replace assertEquals by assertFalse, assertTrue, assertNull
[Form] fix file permissions to 644 again ;)
[Form] add tests for type_options in collectionType
fix file permissions to 644
[Form] add type_options for CollectionType to be abble to set options to type
...
If you use the MinLength validator with your entities, the ValidatorTypeGuesser gets the value, stored as "minlength". Then, the FormFactory generates a "pattern" attribute out of minlength and maxlength.
Modern browsers such as Chrome use this attribute to validate the form before submitting.
a "pattern" attribute is generated that validates the
* bschussek/form-extensions:
[Form] Refactored code from CoreExtension to new ValidatorExtension
[Form] Added FormTypeExtensionInterface
[Form] Reorganized code into "form extensions"
The extension classes are now the only constructor argument of the FormFactory class. They replace the existing "type loader" classes.
new FormFactory(array(
new CoreExtension($validator, $storage),
new CsrfExtension($csrfProvider),
new DoctrineOrmExtension($em),
));
Together with a few upcoming commits this mechanism will make
* extension of the form framework in bundles and
* usage of the forms outside of Symfony2
much easier.
