How is it possible to remove a field that got inherited as doctrine column from mapping?
Example:
In FosUserBundle, I don't need some of the columns (e.g. salt, expiresAt...) within my User class. How can I tell symfony/doctrine to not map this column anymore to the database / remove it from the mapping? I know how to "reconfigure" the columns by using #AttributeOverride, but how can I completly remove a field from the mapping?
Regards.
Pretty much all default properties of the FOSUB User entity are mandatory to make the bundle working as expected.
The fields you given (salt, expiresAt) are related to the security, as the most part of the User properties.
Remove one of them may have side effects in your user management.
Also, you can't Selectively inherit parts of an entity.
Related
Is there a way I can extend a symfony entity in another bundle using #DiscriminatorMap without having to specify it beforehand?
BundleA
Has a class AbstractQueueItem which is a MappedSuperclassfor
Event which is extended by
CreateEvent and DeleteEvent as Single Table Inheritene or Class Table Inheritence
BundleB
How can I add a new Event (i.e. UpdateEvent) to the Event-hierarchy without modifing BundleA?
You can try letting doctrine auto-generate the discriminator map.
From the last bullet point in this section of the docs:
If no discriminator map is provided, then the map is generated
automatically. The automatically generated discriminator map contains
the lowercase short name of each class as key.
So you would:
Omit the #DiscriminatorMap declaration in BundleA.
Extend the entity as normal in BundleB (making sure the short name of each class is unique).
Update the database schema.
EDIT
As pointed out by ju_ in the comments, this solution will apparently not work with Doctrine ORM 3.0, but should still be valid for versions 2.5 - 2.7
I had one class User which is also an Entity type. I need to store information about which user can send a message to another one. My conceptual solution is:
- to make a database table with two columns, except unique id of course (id_sender, id_recipient)
- the next step should be to map my class User to that table (maybe using #joinTable annotation)
What is a good practice for thinks like that? I know I should use the doctrine (as a higher abstraction layer). Thanks for your time!
I currently have a User Doctrine entity and model in my Components. I have a User Bundle that does the basics of working with users, CRUD, etc.
I am developing a resource allocation bundle and I want to extend my User entity to add extra associations without changing the original user. Then the ResourceAllocation Bundle will be completely separate from the User Bundle.
I have setup a mapped superclass of BaseUser, which both User and SkilledUser (the one from the Resource Allocation Bundle). This however, tries to create a table for both User and SkilledUser which is undesired.
The user and skilled user could be the same user, so, Single Table Inheritance is not going to work.
Effectively, the end result should be one table with the users in.
We are working in YAML if answers could keep to this method, that would be great.
"Effectively, the end result should be one table with the users in."
The only way to achieve this is with STI (Single Table Inheritance).
"The user and skilled user could be the same user, so, Single Table Inheritance is not going to work."
I don't see how this matters... you can still create an association between User and SkilledUser if that is what you mean here.
See reference: http://doctrine-orm.readthedocs.org/en/latest/reference/inheritance-mapping.html
I have a legacy application that was using Xaraya to manage user content that I am trying to replace with a rewrite using Symfony/Sonata to manage users and/or content.
For whatever reason, previous developers managed this with two different databases (MySQL for Xaraya, and SQL Server for other things, including authenticating users).
I am trying to create Entity mappings such that the users/groups from SonataUserBundle (which extends FOSUserBundle) use the entity manager associated with the login database connection, and this works for logging into the admin site itself, but blows up when it tries to hydrate objects that have associations to the User entity.
It appears that Doctrine does not try to find the entity manager associated with an entity when hydrating an object's associations.
My question is this: it it possible to make Doctrine hydrate objects using the entity manager for an entity instead of assuming it's mapped to the current entity manager, and if not, is there any form of a clean code work-around for it?
Thanks.
(Note: The method of using the "databasename.tablename" syntax in the query that I have seen mentioned elsewhere will not work for my use case.)
I got a database-table containing fields named like xx_yy_1, xx_yy_2, etc. Unfortunately Doctrine did not generate getters/setters for this fields. I guess this only happens, if there's a underscore in front of a number.
How can I fix this issue?
It is an inconsistent behaviour in Doctrine. You can access does fields like $record->getXxYy_1() or $record->get('xx_yy_1'). The DocBlock on the top of the generated base model class is wrong, so autocompletion may offer wrong method names for these fields.
It's a Doctrine problem. You should name your columns without underscore+number, like:
xx_yy1 instead of xx_yy_1.
So, the method is always ->getXxyy1(); or ->get('xx_yy1')