Is there a way to create Apiplatform enabled entities directly from database schemas?
I successfully create the entities using php bin/console doctrine:mapping:import "App\Entity" annotation --path=src/Entity , but now i have to add manually the reference to Apiplatform resources in 120 entities like here. Is there another way?
Thanks in advance.
This feature isn’t supported out of the box (but it would be nice to add it). There is an open issue to add this feature to MakerBundle, but this hasn’t been implemented at time of writing.
However, you can easily achieve the same effect by using the "search and replace" feature of your IDE or by using sed: find every occurrences of #ORM\Entity and replace them with:
#ORM\Entity
#\ApiPlatform\Core\Annotation\ApiResource
You may want to run PHP CS Fixer after that to change the fully qualified class name by a use statement.
Related
Very simple thing I want to do, however I fail to find a solution.
I have started to develop my app with Symfony4 bundled with Doctrine. At the beginning I have designed database model but during development I have realized original solution is wrong way for what I want to do. Right now, I want to remove an attribute from entity. In plain SQL I would do ALTER TABLE table DROP COLUMN column then recreate it again with new parameters. However this solution gave me an error in Doctrine, so I have changed PHP model as well. Again, another error. Okay, so this does not look like the way I want to go.
Is there any solution to my problem, except digging too deep in Doctrine? Best would be something simple like described in the SQL command above?
When it comes to doctrine with symfony you should forget about tables, columns etc.. and start thinking with objects (otherwise there's no point in using doctrine for abstraction). For your problem you should simply remove the attribute in your entity.
Then You should use :
php bin/console doctrine:migrations:diff
Which will generate a migration file under the /migrations folder. This file will contain the SQL that doctrine will execute. It allows you to verify if the query is what you expect, if not you can directly modify it in that file or adapt your entity and generate a new migration file.
When you are happy with it, you can execute it with :
php bin/console doctrine:migrations:migrate
I'm searching for a way to add a translation to an existing translation catalogue during runtime.
I have a working symfony 2.3 application which uses translations in de/en/fr/it and fetches all available translation keys from /Resources/translations/messages..yml.
Now if a user logs in I want to have the possibility to override some of the already loaded labels based on setting for that user (e.g. textfield in DB which holds key-value-pairs).
E.g.
messages.en.yml
company.name.short: Company profile
Usersetting:
company.name.short: Profile for company
I found no way to add/override keys to the existing catalogue or to make them available in twig. Is there a Bundle or a setting or some Symfony magic to get this to work?
You'll probably want to extend Symfony's own translation class for this. This article explains how to do that:
http://www.webtipblog.com/extend-symfony-2-translator-to-log-untranslated-messages-to-a-database/
The key point is to override the "translator.class" parameter in your config, and then point it to your own class that first checks for database overrules and will defer to the symfony default implementation if it cannot find one.
I've started a Symfony2 project from scratch where I then installed FOSUserBundle.
Then, I have written (actually, generated with ORM Designer) some entities that need to have relations between them, and with the User entity.
I have Items belonging to Users, Collections belonging to Users that group Items, and so on.
Since I used FOSUserBundle I only have a basic User class (https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/Resources/doc/index.md , step 3a) defined using annotations, no config/doctrine folder and no User.yml file in it.
I then created the MyBundle/Resources/config/doctrine folder and added the yml files mentioned above.
When I try to generate the entities with the command-line tool everything works fine: it will create the Entities from my yml files.
However, at this point, trying to load up in browsers the url where the login previously worked (when I only had the FOSUserBundle installed) will throw this error:
MappingException: No mapping file found named
'/var/www/concert/src/X/MyBundle/Resources/config/doctrine/User.orm.yml'
for class 'X\MyBundle\Entity\User'.
Following actions, such as generating the CRUD logic, will not work as long as I have an *.orm.yml file in the config/doctrine folder. If I remove those, CRUD generation will work, but generation of actual mysql tables won't.
Juggling with these gets me to a point where I can also get the tables, but then the actual app doesn't work if I try to use any of the url's where the newly generated CRUD is involved because since the entities are based on yml (which I remove to get things "working") it won't have any mapping knowledge.
Is this inherently wrong? To have yml-based entities in relationship with an User entity based on the FOSUserBundle and still be able to get the nice command-line generation tools?
The problem you describe stems from mixing configuration formats (yaml and I assume annotations). You can easily fix this by ditching the annotations in your models and replacing them with yaml-files like you would do in your own models.
Unfortunately the FOSUserBundle-docs only show you how to use annotations, so here is a quick transformation into yaml format when your X\MyBundle\Entity\User extends FOSUSerBundle's UserEntity:
X\MyBundle\Entity\User:
type: entity
table: fos_user
id:
id:
type: integer
strategy: { generator: "AUTO" }
The remaining stuff is taken care of by FOSUserBundle, as the BaseModel is a mapped-superclass and already describes the stuff in the User.orm.xml, but you could just as well replace the existing values or add additional values just like you would do with your own models.
If you don't use annotations throughout your app, you might also want to disable them in your app/config/config.yml to prevent side effects.
How can I tell Doctrine2 Entity Manager to use an inherited class by default, instead of the generated one?
In my new sf2 app, I generated all entities from the existing database to /src/Package/Bundle/DataBundle/Entity - of course I'd like to have generated forms as well, so I need for my foreign-key relations __toString() methods, which I don't want to put into those generated files because they get overwritten (yes they also get backuped in an extra file, so my changes aren't lost, but manually merging files is not what I want).
So I added new classes to /src/Package/Bundle/DataBundle/Model inheriting all from the entities, but with a __toString() method and surely some other tweaks in the future as well. But now, when I call $entity = $em->getRepository('PackageDataBundle:Customer')->find($id); - I get an instance of /src/Package/Bundle/DataBundle/Entity/Customer instead of /src/Package/Bundle/DataBundle/Model/Customer ..
I'd like to have the behaviour from sf1, where all custom work is done in the inherited classes and the generated ones are the "base" Classes, which can be updated any time on a schema update and aren't touched otherwise..
I hope there is some configuration for this..
Maybe as a bonus, I'd like to have my naming convention turned around: to have Model as the "abstract" generated one and Entity as the actual used one
Thanks.
I'd like to have the behaviour from sf1, where all custom work is done in the inherited classes and the generated ones are the "base" Classes, which can be updated any time on a schema update and aren't touched otherwise..
For purposes you described you should use Propel ORM - it was so in Symfony-1.4, and became even more flexible for Symfony-2.0 with Propel 1.6. It is well documented, easily installed and naturally used within Symfony-2.0
Perhaps I misunderstood your problem, but going from Propel to Doctrine i was also disappointed that there is no way to keep that "dirty" auto-generated code out of my logic.
I do not know how much it is now important to you, but I currently writing a simple bundle that implements such generation style.
$ app/console doctrine:generate:entities СompanySomeBundle --propel-style=true
Generating entities for bundle "СompanySomeBundle"
> backing up User.php to User.php~
> generating Сompany\SomeBundle\Entity\Base\User
> generating Сompany\SomeBundle\Entity\User
https://github.com/madesst/MadesstDoctrineGenerationBundle
PS: Sorry for my english =/
I'm trying to create a join across multiple databases (one of them belonging to a legacy application) as described in the Doctrine blog. However, the example suggests hardcoding the name of the database right into the schema, which I'd like to avoid for obvious reasons.
Is there a way to read parameters defined in parameters.ini or config.yml and use them as a value for the annotations, like this?
/**
* #ORM\Table(name="%legacy_db_name%.%legacy_table_name%")
*/
No, it's impossible. The "%key%" form is only available in the DIC.
Why would you put these data in a yml file? Would it be useful?