use the new doctrine compiler pass to map the model classes directly

[dbu]

this is to show how we would use the compiler pass of the doctrine bundle to map our model classes directly. See symfony/symfony#7599

this is done for orm, mongo and couch. we have a simplified compiler pass in this bundle for backwards compatibility with symfony < 2.3. that can be removed once this bundle is declared to only work with symfony 2.3.

[stof]

This is a BC break for users: If they extend Entity\User, they won't get the inherited mapping of the MappedSuperclass anymore as Doctrine ORM stops reading metadata when it finds a transient class (not lookign if parent classses are mapped)

[dbu]

oh, that was not intended. then we would need to keep an empty mappedsuperclass mapping for this class? otherwise we rather should delete the class right away to make people notice the BC break. which do you prefer?

[stof]

@dbu I would prefer keeping a mapped superclass for the entity (with no mapping it in as everything is inherited) to keep the BC

[dbu]

alright, will fix that (on monday, the weather is just too nice to stay inside for a long moment :-)

do you have input on the listeners locations? and i plan to write a cookbook entry describing best practices for bundles providing multi-database models - what could be a better folder strategy if a bundle indeed needs a persistence specific model class for some reason? (like PHPCR-ODM having a parent and a name field)

[stof]

@dbu As listeners are specific to Doctrine, I suggest Doctrine if they are common to all and Doctrine\(ORM|PHPCR) if they need to have different implementations (eventually putting them in a Listener subfolder if you also need custom repositories and custom doctrine types for instance).

[dbu]

adjusted to the factory method of the compiler pass and re-added empty mappings to keep BC

[dbu]

should i copy the compiler pass into FOSUserBundle so that we have a workaround until we can depend on the right symfony bridge and doctrine versions? otherwise things would not be backwards compatible as the mapping on Entity/Document/... is just a stub now and relies on the class in Model being properly mapped by doctrine.

[dbu]

i added support for mongodb now. i think it works, though i have no clue of mongodb. when the mapping is active i get

> db.system.indexes.find()
{ "v" : 1, "key" : { "_id" : 1 }, "ns" : "test_database.User", "name" : "_id_" }
{ "v" : 1, "key" : { "usernameCanonical" : 1 }, "unique" : true, "ns" : "test_database.User", "name" : "usernameCanonical_1" }
{ "v" : 1, "key" : { "emailCanonical" : 1 }, "unique" : true, "ns" : "test_database.User", "name" : "emailCanonical_1" }

when the parent mapping did not work, i only got the _id so it does something. i never got more metadata in mongo, even when using the old mapping with the Document folder. so i hope its correct what i do here.

[stof]

could you move this logic into a private method if you want to return early ? this will void weird issues if someone else adds another piece of code in build later and does not notice this early return

[dbu]

good point. i will add a fallback instead of return here, but still keeps the code more understandable

[stof]

We should find a way to keep the compatibility with Symfony 2.2. I would like to avoid maintaining 2 versions of FOSUserBundle if possible

[dbu]

i moved things into a method and added a legacy support compiler pass (yeah symfony 2.2 is already legacy...)

[dbu]

how to handle couch, as the couch bundle is not even installable with symfony 2.2? should i just add legacy support for the mapping for it and test with symfony 2.1?

[dbu]

i somehow tricked couch to get installed in my testbed and made things work. see doctrine/DoctrineCouchDBBundle#27 - i think mapped superclass is broken in couchdb, so no clue if what fos userbundle was offering was ever working at all. with the fixes discussed in the couch bundle PR i get things to work however, so imho we can merge here and hope couchdb bundle gets fixed someday. we don't break anything that used to work as far as i can tell.

[dbu]

i just wrote this assuming there will be a 1.3.2 sometimes after this PR is merged, and that we want to drop the classes in 2.0. we can also do it later, they don't really hurt (except the eyes :-)

[stof]

master is the dev branch of 2.0, not the maintenance branch for 1.3. So it won't be in a 1.3.2 release

[dbu]

Ok, then we dont want to have this in any 1.x branch? Just thinking it should be available asap so that people Start using it. Do we need the bc entity classes in 2.0?

[stof]

I would say yes for now, to avoid breaking hard for people already using 2.0.x-dev. but with a trigger_error(E_USER_DEPRECATED) in the constructor so that they know they need to change their code before 2.0 stable.

[sroze]

@dbu I've the same problem. I updated FOSUserBundle and I got this error.
I (we) have a user model that extends Model\User on which I added my own mappings, especially I have my own roles voter and I don't save them in the user model.
To make it working after this pull request, I had to remove every of my mappings that are also in Model\User and now I have a "roles" field in my table, but I don't want, and I have no choice...

[dbu]

ah, now i got what you mean. hm, indeed i see the issue. a quickfix you can do is

• have Model\User class in your bundle that just extends the FOSUserBundle Model\User. but no mappings or anything for it
• then extend that class from Entity\User

doctrine walks the class hierarchy to find mapped superclasses, but as soon as it encounters a class not mapped it stops. if i am not totally mistaken this way you get rid of the base mapping.

alternatively you can just copy the methods and fields from the FOSUserBundle User class into your class and not extend anything, but just implement UserInterface. then you don't have any methods or fields on the class you don't need (like when you don't need a roles field at all).

@stof what would be the clean solution for this? using "custom" instead of "orm" for the manager type would prevent the mapping from happening, but then one would have to manually ensure the doctrine listener gets loaded and tagged. do we need a different parameter fos_user.backend_type_orm_map that defaults to fos_user.backend_type_orm but can be overridden to not load the mapping but still load the orm services? (and similar for couch and mongo of course). Or should we promote not extending the Model\User but implement UserInterface?

[mvrhov]

@dbu we really need a way to disable the automatic loading of mapping information.

P.S. Disabling it by trying to unset fos_user.backend_type_* cannot work as the container builder doesn't have the functionality to do so...

[dbu]

if you set the storage to custom, you won't get any mapping driver
active. you then might want to manually load the orm.xml and
orm_group.xml from Resources/config/ if you still want the user manager
and user listener services.

[juanmf]

It'd be cool to have an example snippet of how to override the mappings, for instance to see how to implement roles differently. I've seen many questions around with misleading answers. I don't know if this is the recommended implementation of an override but this is what I could do by reading your docs, which are great by the way.

Edit: just created a repo with this bundle: https://github.com/juanmf/UserBundle

[merk]

@dbu Now that doctrine/DoctrineBundle#177 has been tagged in a release we're seeing a few people report that there are weird errors with compiler passes conflicting when using 2.0@dev of this bundle and 1.3@beta of DoctrineBundle.

Is there something that needs to be done in FOSUserBundle to make sure we're compatible with DoctrineBundle 1.3?

[dbu]

@merk: from users using doctrine orm or something else? https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/DependencyInjection/Compiler/RegisterMappingsPass.php is a copy-paste of the compiler pass in DoctrineBundle, as at the time (and still) we wanted to support symfony < 2.3 and DoctrineBundle < 1.3. there is this check.

the doctrine code is this, the code that is used with older Doctrine versions provided by this bundle is this

i don't see the semantical difference or what we do, or a bug. but maybe there is - what exactly are the errors that come up?

[merk]

I'll go through my logs to see what was said exactly, sorry - I should have done that before pinging you.

[dbu]

no worries. i had a good look at the compiler pass again and at least
can confirm that DoctrineBundle 1.2 does not provide the pass yet, so
only 1.3 leads to using the compiler pass provided by symfony + doctrine
instead of the local one.

[richardudovich]

hey guys, ive been following the following instructions...
http://stackoverflow.com/questions/22718628/fosuserbundle-override-roles-property-roles-in-acme-demobundle-entity-user
but im getting "Unrecognized field: usernameCanonical" error when trying to
authenticate... , ive debugged it and can see that getClassMetadata does
not return the meta data of inherited class, but i am not sure why... if
anyone can give me a hand with this would be appreciated...

im using same version of fosuserbundle as in the stackoverflow post...

On Tue, Aug 5, 2014 at 4:09 PM, David Buchmann [email protected]
wrote:

no worries. i had a good look at the compiler pass again and at least
can confirm that DoctrineBundle 1.2 does not provide the pass yet, so
only 1.3 leads to using the compiler pass provided by symfony + doctrine
instead of the local one.

—
Reply to this email directly or view it on GitHub
#1081 (comment)
.

Regards

*This e-mail and any attachments may contain confidential and privileged
information. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this e-mail and destroy any
copies. Any dissemination or use of this information by a person other than
the intended recipient is unauthorized and may be illegal. *

[juanmf]

@richardudovich have you edited your composer.json as shown? (And composer
updated)
El ago 6, 2014 1:57 a.m., "richardudovich" [email protected]
escribió:

hey guys, ive been following the following instructions...

[richardudovich]

Hey, thanks for getting back to me, i have updates my composer file...
I have included it here for a reference: http://pastebin.com/0viTPgMM

On Wed, Aug 6, 2014 at 10:41 PM, Juan Manuel [email protected]
wrote:

@richardudovich have you edited yor composer.json as shown? (And composer
uodated)
El ago 6, 2014 1:57 a.m., "richardudovich" [email protected]
escribió:

hey guys, ive been following the following instructions...

http://stackoverflow.com/questions/22718628/fosuserbundle-override-roles-property-roles-in-acme-demobundle-entity-user
but im getting "Unrecognized field: usernameCanonical" error when trying
to
authenticate... , ive debugged it and can see that getClassMetadata does
not return the meta data of inherited class, but i am not sure why... if
anyone can give me a hand with this would be appreciated...

im using same version of fosuserbundle as in the stackoverflow post...

On Tue, Aug 5, 2014 at 4:09 PM, David Buchmann [email protected]

wrote:

no worries. i had a good look at the compiler pass again and at least
can confirm that DoctrineBundle 1.2 does not provide the pass yet, so
only 1.3 leads to using the compiler pass provided by symfony +
doctrine
instead of the local one.

—
Reply to this email directly or view it on GitHub
<

https://github.com/FriendsOfSymfony/FOSUserBundle/pull/1081#issuecomment-51153987>

.

Regards

*This e-mail and any attachments may contain confidential and privileged
information. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this e-mail and destroy any
copies. Any dissemination or use of this information by a person other
than
the intended recipient is unauthorized and may be illegal. *

—
Reply to this email directly or view it on GitHub
<
https://github.com/FriendsOfSymfony/FOSUserBundle/pull/1081#issuecomment-51293897>

.

—
Reply to this email directly or view it on GitHub
#1081 (comment)
.

Regards

*This e-mail and any attachments may contain confidential and privileged
information. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this e-mail and destroy any
copies. Any dissemination or use of this information by a person other than
the intended recipient is unauthorized and may be illegal. *

[juanmf]

Mmm.. Are you activating these mappings in your config.yml?

doctrine:
    orm:
        auto_generate_proxy_classes: "%kernel.debug%"
#        auto_mapping: true
        default_entity_manager: default
        entity_managers:
            default:
                connection: default
                mappings:
                    ApplicationUsuarioBundle: ~ # This is my UserBundle.

I think it might be more accurate to follow this discussion in stackoverflow...

[richardudovich]

Nope, i am using auto_mapping: true

On Thu, Aug 7, 2014 at 12:53 AM, Juan Manuel [email protected]
wrote:

Mmm.. Are you activating these mappings in your config.yml?

doctrine:
orm:
auto_generate_proxy_classes: "%kernel.debug%"# auto_mapping: true
default_entity_manager: default
entity_managers:
default:
connection: default
mappings:
ApplicationUsuarioBundle: ~ # This is my UserBundle.

—
Reply to this email directly or view it on GitHub
#1081 (comment)
.

Regards

*This e-mail and any attachments may contain confidential and privileged
information. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this e-mail and destroy any
copies. Any dissemination or use of this information by a person other than
the intended recipient is unauthorized and may be illegal. *

[dbu]

hm, could it be that auto_mapping collides with this bundle registering the mappings?

for FOSUserBundle 2.0, we should probably completely drop the BC code in Entity and Document to avoid this issue.

[richardudovich]

So, at the end of the day i just want to know if the example posted in the
previous email actually works? considering same version as shown in the
example are used... can anyone actually verify this?

On Thu, Aug 7, 2014 at 4:17 PM, David Buchmann [email protected]
wrote:

hm, could it be that auto_mapping collides with this bundle registering
the mappings?

for FOSUserBundle 2.0, we should probably completely drop the BC code in
Entity and Document to avoid this issue.

—
Reply to this email directly or view it on GitHub
#1081 (comment)
.

Regards

*This e-mail and any attachments may contain confidential and privileged
information. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this e-mail and destroy any
copies. Any dissemination or use of this information by a person other than
the intended recipient is unauthorized and may be illegal. *

[juanmf]

@richardudovich I'm using this USerBundle in two different projects successfully. I'll make a repo with it, I might have missed something in my documentation. Let me know if you manage to make it work and why didn't it work before..

Done: https://github.com/juanmf/UserBundle

[richardudovich]

Thanks, that would be appreciated

On Thu, Aug 7, 2014 at 6:09 AM, Juan Manuel [email protected]
wrote:

@richardudovich https://github.com/richardudovich I'm using this
USerBundle in two different projects successfully. I'll make a repo with
it, I might have missed something in my documentation.

—
Reply to this email directly or view it on GitHub
#1081 (comment)
.

Regards

*This e-mail and any attachments may contain confidential and privileged
information. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this e-mail and destroy any
copies. Any dissemination or use of this information by a person other than
the intended recipient is unauthorized and may be illegal. *

[dbu]

we had this discussion: doctrine/DoctrinePHPCRBundle#152 (comment)

The issue is therefore triggered when:

1. You are using automapping
2. You have a Document namespace
3. You have mapping files in the default Resources/config/doctrine folder
4. The classes in your Document namespace are NOT odm documents but are named the same thing as your odm documents

but i don't think we have this situation here.

are people having problems using orm or mongo or couch?

[richardudovich]

Well if Juan can create repo with his version working just so i can get an
idea that would be appreciated.

On Fri, Aug 8, 2014 at 10:02 PM, David Buchmann [email protected]
wrote:

we had this discussion: doctrine/DoctrinePHPCRBundle#152 (comment)
doctrine/DoctrinePHPCRBundle#152 (comment)

The issue is therefore triggered when:

1. You are using automapping
2. You have a Document namespace
3. You have mapping files in the default Resources/config/doctrine folder
4. The classes in your Document namespace are NOT odm documents but are
   named the same thing as your odm documents

but i don't think we have this situation here.

are people having problems using orm or mongo or couch?

—
Reply to this email directly or view it on GitHub
#1081 (comment)
.

Regards

*This e-mail and any attachments may contain confidential and privileged
information. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this e-mail and destroy any
copies. Any dissemination or use of this information by a person other than
the intended recipient is unauthorized and may be illegal. *

[xabbuh]

@richardudovich It's https://github.com/juanmf/UserBundle, isn't it?

[juanmf]

@ChristianFlothmann Yes. That's it. Sorry I could not reach the laptop. CC
@richardudovich
El ago 10, 2014 1:30 p.m., "Christian Flothmann" [email protected]
escribió:

@richardudovich https://github.com/richardudovich It's
https://github.com/juanmf/UserBundle, isn't it?

—
Reply to this email directly or view it on GitHub
#1081 (comment)
.