Is there any way to create data objects for MySQL database tables using Zend_Tool?
What I am trying to achieve is to create setter/getter methods and column variable of any table in some class by using command line zf utility. (like we can do it in pear)
You would need to create your own providers for Zend_Tool.
Essentially, you create a class that extends Zend_Tool_Project_Provider_Abstract. Every public method becomes an action available within the zf.sh tool.
You also need to register your new provider with Zend_Tool. Do this by running:
run zf --setup storage-directory
run zf --setup config-file
edit ~/.zf.ini and add php.include_path and basicloader.classes.0 entries that point to your new provider's path and classname respectively.
Further details: http://akrabat.com/zend-framework/akrabat_db_schema_manager-zend-framework-database-migrations/ & https://github.com/akrabat/Akrabat/blob/master/zf1/Akrabat/Tool/DatabaseSchemaProvider.php
Related
I am developing a little application with PHP web framework Laravel v6 and MongoDB (with jenssegers moloquent) as database engine. This is my first encounter with any MVC framework. I have the following collections in my database:
allPaintingsCollection
paintingHistoriesCollection
paintingCategoriesCollection
artGalleriesCollection
paintingArtistsCollection
supervisorArtistsCollection
smPlatformsCollection
nonSmPlatformsCollection
targetSchoolsCollection
I have been following this tutorial. I have the following two questions:
Do I have to create a separate Model (separate class in a separate file) for each collection above?
Do I have to create a separate Controller (separate class in a separate file) for each collection above?
New Answer:
1. Yes, you will need to create a separate model to use the ORM. Ideally, the model should only support a single collection, doing so you can create custom logic. Remember, One Model One Collection/Table.
For Controllers, you can write it any way you like, you can use all models inside a single controller. But what I have learned so far using Laravel, you should create a single controller for each model to fully and logically support the separation of concerns.
Know the BTS:
Laravel heavily uses PHP Composer's autoloader functionality, so having multiple classes in a single file won't work.
For example, when autoloader starts, it would look for User class in \App\Models\User.php file. Having multiple classes in a single file won't help in this case.
Latest Laravel's version follow PSR-4 standard. You can have a look at it for more understanding.
For more PHP coding standards you can have a look at PSR-2 standards.
Just out of sheer laziness, I'm interested in knowing whether there's a command that will allow me to add a single field to an existing Doctrine entity, using prompts similar to the ones that appear when I run doctrine:generate:entity. Does such a command exist?
(For now, I'll go ahead and manually add my property, getters and setters in the entity's PHP file. I'm just curious about whether there's a CLI way to do it.)
Yes, there is. If you are using Syfmony 3.x or Symfony 4 you can install the symfony maker bundle (composer require symfony/maker-bundle).
Then, you can run the command php bin/console make:entity and select an existing entity name. It will detect that is created and allow you to add fields dynamically.
UPDATE: And it's not laziness. Code generation tools save time in repetitive tasks and allow you to focus more on your business logic. :)
No there isn't a command to add a new property to an existing entity because is no sense to do it I think.
For example if you want to add a new property you can add simply into the entity file and after you can launch the command to generate getter and setter.
Add a new property to an existing entity is very easy but it's not possible with a command.
Another way could be to use migration but you don't do it all by the CLI.
So the answer is:
if you want to add a new property add it into the entity file and after generate getter and setter
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();
I'm looking for ideas to properly handle my project's mysql table updates across environments. I've taken a look at the CI DB Forge class and I believe this might help me out a bit. My thoughts are to:
create a new file for each database install, table upgrade or change. The file would contain the raw mysql query to do each relevant task
run the upgrade scripts via hooks before any controllers are loaded
continue loading the project
Is this the correct thinking? This is pretty similar to how Magento handles database upgrades per extensions.
Sounds like you are looking for the Migrations class. This is a fairly new library, and the documentation at this moment is not too good in my opinion.
If you enable this library in application/config/migrations.php and load it, the it will create a database table called migrations. The workflow from there is the following:
Create a new file under application/migrations make sure you name it with sequentially numbered file name like 001_some_descriptive_name.php. The format is important, exactly 3 numbers and at least one _ after them.
In the new file create a class named after the file name, so the 001_some_descriptive_name.php should hold a class called Migration_Some_descriptive_name and extend the CI_Migration class. The class name casing is important, first Migration_ then one uppercase letter then lowercase.
Create a public up and a public down method inside the class
Inside the up method add your migration code, that changes the database. You can use the db forge library or just plain old $this->db->query() calls. Dbforge is more portable if you need to support multiple database systems its probably better to use that.
Inside the down method add the code that would reverse the effects of up. If up adds a column then down should drop that column, if up creates a table, down should drop that table and so on.
Once you finished your migration class bump the migration_version inside the migration config file.
Create a controller load the migration library and call $this->migration->current() this will check the version from the migration database table and run the migration classes up or down methods in order to reach the migration version in the config file you set at step 6. So for example if the database says you are at version 2, and the config says you should be on 5, then it will run the up method of the migrations with 003_..., 004_..., 005_.. filenames in order. If you set lower number then the current the down methods will be called. The database starts the counting from 0 so don't create a 000_... file.
If you feel adventurous you can create a hook that loads the migration class and runs the get_instance()->migration->latest() on every page load so every environment will auto update the db once you deploy a new migration class.
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).