I've been looking into PHP-frameworks lately to find out which suits me best. I've had some experience with the java Play! framework which did some very nice things. One very nice feature that I haven't found in Laravel yet, is that when you edit your model, it can generate migrations for you. Is there a way in Laravel to generate migrations automatically from edits on your model? This would seem like a huge improvement to me, since migrations seem like a bit of a hassle to me right now.
I'm looking forward to your opinions and help!
You only specify the columns in the migration and not on the model, so you don't have to edit anything on the model.
You first specify the columns (properties) for a table in the migrations.
Then you use those properties in your Eloquent Models.
You don't have to put all properties in the model, when you create a column with a migration it is accessable via a model, without also specifying it in the model.
Related
I was given this project to work on with absolutely no documentation or contact developer. I noticed in the database dump that they are storing what looks like PHP Namespaces for Eloquent models in a couple tables. For example an address table has a string column named "object_type" with the value always being "App\Entities\Client". I searched through the whole project for the PHP code that would use this value. Hopefully to give me insight to it's purpose. Not to my surprise, the project never uses this value. I just see it hard-coding these values upon insert into the DB.
My question is, is this some sort of Database and/or ORM modeling design practice? If so, could you explain how this could be used in a simple practical sense?
Maybe this was some concept the developer had and it never evolved. It's interesting idea but, the idea of joining through MySQL on a string conditional sounds like torture.
Sounds like Laravel polymorphic relationships:
Custom Polymorphic Types.
By default, Laravel will use the fully qualified class name to store the type of the related model.
And, yes, this is a valid modeling technique, though purists rightly argue this technique abuses normal form.
I am not sure what the developers where thinking.
But imagining we are in a forum with thread and replies to each thread. We maybe want to have a Favourites table where we can save replies and threads.
A way to do it would be to have a column in the favourites table called "object_type" (just to use the same term you have in your case) and then when we save an object into the database with eloquent we can use:
$favourite->object_type = get_class($thread); //or get_class($reply) in case we want a reply
$favourite->save();
This way will save the namespace of that class into the database. But laravel will recognise it when we get it from the database.
Hope this cold be helpful.
My question is if it is possible to add all the fields directly to a new model via Eloquent.
I guess it would be something like
php artisan make:model MyModel --fields=?
However, I can't find anything related with that. Anyway, I have to generate a lot of model and any trick would be really appreciated.
Thanks in advance
If you mean table's column by fields then:
Firstly you don't need to define fields in modal. I mean in Laravel no need to define fields while creating model. Besides, model automatically work with your database table's columns as its property.
So, now you may want to define columns while creating migration, not while creating model. There is library to serve this demand named as Generator(https://github.com/laracasts/Laravel-5-Generators-Extended) maintained by Laracasts.
Using this generator you can generate migration file to create table in DB specifying their column names and their type also. Here is a example from their Github repo, how you can do this:
php artisan make:migration:schema create_users_table --schema="username:string, email:string:unique"
You can checkout their documentation for more information. Best of luck.
It's not possible with make:model or make:migrations commands, but you can create your own console command and add this feature by yourself.
Also, take a look at source code of make:model and make:migration commands to get some ideas on how to do that.
it looks like only built in options are --migration and -m to include a migration with the model generation. L5.3 Docs
There does look like there is a package for L5.0, which looks like it would work in 5.*+. It is put out by Laracasts:
https://github.com/laracasts/Laravel-5-Generators-Extended
It also looks like you can make a custom solution as well:
https://laracasts.com/discuss/channels/tips/l5-artisan-command-makemodel
Hope that helps!
No options while creating a model,
This is my terminal output (laravel 5.3) while i check,
You don't need to mention fields while creating model.
Ex:- based on the rules you should keep the names as like below,
model name as User
table name as users
then the model automatically handle everything, you don't need to mention the table/fields name.
I was looking for the same thing myself, as I used to work like that in previous frameworks, but could not find it, or at least not as I wanted it, so I did my thing. You can check it out if you like:
https://github.com/Triun/laravel-model-base
It will read your database, and create the laravel eloquent models for you.
It is meant to be very flexible, so the configuration may be a little complex, and I guess that I didnt' catch up with the documentation, but you can ask me if you don't know how to make it do what you want.
Basically it has 4 customization levels:
By out of the box modificators, configurable by the config files.
Including interfaces and traits to your auto-generated models.
Create your own modificators. Classes where you receive the model skeleton before it is saved, so you can add or remove properties, methods, etc.
Generate the model base, but edit yourself the final model.
And, of course, suggestions and contributions are more than welcome.
My question is more theoritical, as I am not quite sure if it is a better way to create a model in Laravel for each table on database, if yes, what would be the benefition of it?
I am using Laravel 4 Eloquent for the ORM.
Thanks
The basic answer is yes, you should have a model for each table.
But the long answer is "it depends". As for what "depends" is, it is something that comes with experience and also your design criteria. There is no 100% right answer that can be used everytime.
As a principle if you plan on accessing data from tables using Eloquent, then you generally need one eloquent model per table, so you can access the table using Eloquent functions.
As a principle you dont need a model if you never use Eloquent to access the data. i.e. perhaps you have a table that you only use the query builder on.
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.
Firstly, I would like to just it out there that I am an ORM noob. I've never used an ORM in my life and have reached a point in my day-to-day developing that I need to do some crazy advanced relationships that I believe Datamapper Overzealous Edition can help me with as I am using Codeigniter.
In my database I have the following tables;
users
projects
clients
tasks
Here is my desired relationships between the tables;
A user can belong to many projects.
A project can have multiple tasks, but can only have one client.
A client can have many users and can have many projects
A task can only have one project
I have attempted to set-up my models in the models directory as it says in the documentation the model name without the s on the end, so for users I have a user.php model and so on.
I know the documentation is great, but I just can't seem to understand it properly even though it is obviously very easy. I know you instantiate the model by going for example $u = new User(); inside of your controller, but my question is setting up the relationships inside of the models.
How do I set out my models to have the above relationships so for example when I fetch a task I can see what project it belongs to and a whole heap of information from its associated database tables.
I noticed that in the documentation you use the following inside of the projects model which should tell it that it can have more than one task for a project; var $has_many = array('task')
Is that all there is to it? Is it as simple as defining the $has_many and $has_one variables and putting in the associated model name in the array?
I've never used this particular ORM but I do use Doctrine. If the one you are using works in much the same way then the simple answer to your question is - yes! With Doctrine you set up all relationships in the model classes. The ORM will then manage it all for you. So, for example, if you instantiate a new task object...
$task = new Task();
Then you can access the relationship with the Project table by simply writing
$task->Project;
I must stress that the above code is not written for datamapper so might not work as is, but I hope it clears things up for you. It sounds like you do understand the documentation but just don't believe it!!!!
That is all you have to do as long as your database structure fits the layout expected by Datamapper Overzealous.
I've been using this ORM in a project I've been building and for the most part, it's been extremely helpful and time saving.