I'm currently rebuilding my current website using Symfony 2 instead of the previous Codeigniter framework it was running on. I'm completely new to Doctrine too, and I'm having a little trouble working out the best place to put a complicated-ish MySQL query.
I have a service container currently that uses this query via prepare($sql)->execute(), and various functions that use the data it provides. As it stands now, I pass doctrine to the service container, and run the query within. I then use the same service container to do what I want with this data.
To me, it just doesn't feel right fetching and using the database data in the same class? Should I put the execute() query in the entities folder at the bottom of the Doctrine created file, in the entities folder in it's own file, or is it fine where it is?
I think, it will the be better way to create a custom repository class in Repository folder for some actions by preparing entity data.
You can read more about custom repository here custom-repository-classes
Further repository can be used throw doctrine.
For example:
$container->get('doctrine')->getRepository('YourBundleName:Entity')->someRepositoryMethod();
Related
There does not seem to be proper documentation available on how to configure and use database views with the doctrine migrations bundle.
One probably is not able to map SQL statements which will end up creating/updating a database view (from the sql given somewhere) when migrations:diff and migrations:migrate are run.
If an entity is mapped to a database view with the #table(name="view_name") markup, it ends up causing an error / new table being attempted, instead of understanding that its a database view being used.
Is there a solution? Am I missing something?
I'm not sure that doctrine can get out of the box views. For all I know, you'll have to cheat.
Or:
I think you have to write the migration script yourself.You can generate an empty one and then write the create-statements into it.
In the repository you integrate native sql. The result you map to your entity or DTO.
https://www.doctrine-project.org/projects/doctrine-orm/en/2.7/reference/native-sql.html
I am building a PHP Laravel v5.3 app that will function as a Notebook with Notes and Tags as well as Note revisions/versions which can be used to restore a Note record to an older version of the Note.
It is basically an EverNote Clone in PHP similar to the open source Project Paperwork but will not be using AngularJS.
Based on that description above, my project has these Models:
Notebook
Note
NoteVersion
NoteTag
I have these Controller Classes to process the incoming HTTP Requests to the server Notebooks, Notes, and NoteVersions.
I need to have a function that will query the database for 2 NoteVersion records and return them as part of a JSON response which will be used as part of a view to show a comparison of 2 Note Versdions so a user can see the difference between the 2 records.
So assuming I add a new Controller Method to build this view, if I don't want the COntroller Method to handle the whole process of query the Database and doing all the work, what type of File would I put a function like that in instead?
Assume the function I want to build is like this:
get2NoteVersionsForComparison($currentNoteId, $oldNoteId);
In my controller method I want to call this method get2NoteVersionsForComparison($currentNoteId, $oldNoteId) and have it return a JSON response.
So where best would my get2NoteVersionsForComparison($currentNoteId, $oldNoteId) method live at?
A Repository, Model, ServioceProvider?
I like to create a new project or company-specific folder and create a class in that folder. So, for example, App\Acme\MyClassFile.php would be the location. Create classes that do everything else. Sort of like a repository, if you will. But where doesn't matter as long as you use proper namespacing.
I'm trying to teach myself ZF2 in conjunction with Doctrine 2. I've completed both the Album tutorial and Blog Tutorial on Zend's website successfully. Now I'm trying to go back and convert the Blog Tutorial to use Doctrine 2. I believe I've successfully setup my config for doctrine and used DI to get it inside of my controller (WriteController.php) since I am able to dump the contents of it within my action. I don't get any errors so long as I don't do anything with it.
My question is what roll does Doctrine take in the Controller -> Service -> Mapper -> Backend layered structure which was taught in the Blog tutorial? (Reference To what I mean)
Also, I'm assuming Backend is referring to my Models. Is this correct?
Would I just replace any references to /Blog/Model/Post with /Blog/Entity/Blog?
The Doctrine is the Mapper. And maybe we could say also the Service (through EntityRepository). But usually you will create your own Service Layer.
The Backend is not the entities it self. Entities in one way to map the several options of backend. As backend you can understand the several options of Relational Databases (Mysql, SqlServer, Oracle, etc) NoSql Databases (like MongoDB), file system and so on.
I didn't understand your last question. But when I use Doctrine I always create my entities in /MyModule/Entity namespace. While when I use the standart Zend/Db I always create in /MyModule/Model. I do that by standardizing matters.
What I'm trying to figure out is how to add new fields to a table, using Symfony2 with Doctrine2.
I used this to initially create the Entity:
php app/console doctrine:generate:entity --entity="MyMainBundle:ImagesTable" --fields="title:string(100) file:string(100)"
And I used this to create/update the tables on the database:
php app/console doctrine:schema:update --force
Now if I wanted to add new fields to the ImagesTable entity, is there an easy way to do it using the console, or do I have to manually edit the entity. I am just using 1 entity as an example right now, but in reality, there are many entities I'd be changing; so, there has to be an easier way to do it.
I've been manually editing them to create relationships, so if there is an easier way to do that as well, that'd be great.
I remember this being a lot easier with Symfony1.4 - all I had to do was create the database/tables using phpMyAdmin, and Symfony was able to generate the models with no issues.
I really hope I'm missing something here, because this won't work if I have to manually edit every entity for every change.
Doctrine generator commands are intended to help the developer to quickly prototype an idea. They generally don't produce production ready code, and the code needs to be checked to see if it contains what you want.
You can still create your model in phpmyadmin and use Doctrine reverse engineering tools, but it also doesn't produce production ready code, only intended to use in prototyping.
Creating database/tables beforehand doesn't really work well with Doctrine2, as the underlying relation between tables may not be the same as the relation between objects of your model. The whole point of ORM is to think in classes and letting Doctrine do the rest of the work for you.
Doctrine is not intended to write your entities for you, it gives you tools to build your data model, which you use to code your model in Php.
If you don't like to code your entities by hand (which is what all developers using doctrine does), you may want to have a look at RedbeanPHP, a zero-config ORM framework for PHP. It creates the database tables, columns, indexes on the fly depending on the data model you use.
I'm working on a Symfony 1.4 project with Doctrine 1.x, and functionality that merits using a Doctrie_View (as an interface for native MySQL Views).
As I understand it, the View (as in DB View as opposed to the View in MVC) has to be created wth Doctrine so that Doctrine can maintain the association between the View and the original Model from which it's derived.
In an ideal world, I'd like to have the View created as part of the symfony doctrine:build --db task. The sensible way to do this would be to use the observer pattern and Symfony's Event Dispatcher, however, the list of Built In-Events doesn't seem to offer an event for when the database schema is built.
So, what's the best way to have a Doctrine View created when the schema is built?
Or perhaps, if that's not an option, check if a View doesn't exist and then create it as part of ProjectConfiguration::configureDoctrine()?
doctrine:build-sql
I think you should rather look at the doctrine:build-sql task which builds the sql instructions from the model definition.
If you look at the sfDoctrineBuildSqlTask class you'll notice it's rather simple. It really only calls the doctrine cli. If you want to hook into it you should check the Doctrine events rather than symfony.
migrations
What you could also do is creating your view in doctrine migrations. Whenever you need to change your view you'll create another migration (removing old and creating new view).