can you tell me relationship
anyone here that can correct Exclude, include
Related
I’m using the HasDuplicates trait on my Post custom entity.
The Post has 2 relations:
has many comments
has one author
How can I configure the duplicate functionality in order to duplicate a post record along with its relationships: comments and author?
I see in your documentation that I have the option of excluding relations, but not to include them.
The Varbox\Traits\HasDuplicates automatically duplicates all your eloquent model relationships by default, so that's why there's no option to include any relationships to be duplicated, because they all are duplicated by default.
Also, in the event where you don't want certain relations duplicated (such as belongs to relations), you have the option to exclude them (as you already stated): https://varbox.io/docs/2.x/duplicate-records#exclude-relations
So to answer your questions, you don't need to do anything to include your comments and author relations into the duplication functionality, as they will be included by default.
Suggestion: Depending on your database structure and logic architecture, I think you should consider converting the author relation into a belongs to, instead of has one, but that's up to you.
I have a doub about Laravel. The models are used to define the relationships between the models like hasMany, belongsTo, etc. Also the models are used to define the fillable fields. But he models are only for that? Because I already check some examples that it seems that some queries are executed in the models instead of the controller so Im not understanding if the models should also have the querying of the relationships or not. Can you give a help to understand better what is the correct use of models (what should be placed in the models)?
Its same way to execute queries on model or controller. Written queries in model make your controller more clean. We can write mutator, accessor or query scope in eloquent model. Correct me if I'm wrong.
Visit https://laravel.com/api/5.5/Illuminate/Database/Eloquent/Model.html
You can refer this documentation, it's quite helpful if you want to know deep basics and responsibilities about particular part in Laravel.
Models are mostly used to make an outlook of the data i.e what fields are going to be saved in the database and we also use it to associate the relationships with other related data as you already know but we also use it to alter the values that are either going in/out of the data base which you can check in the documentation in link bellow https://laravel.com/docs/5.6/eloquent-mutators
the main purpose is to divide the code between controller and model (were it best fit to be)
I currently do have a vehicles table that holds "Cars".
Now I want to allow the system to have Bikes, Cars and Trucks.
They have some fields in common (manufacturer_id, mileage, ... ) but they also have specific fields (Bike: cylinder_capacity, seats; Car: doors, ...)
I have tried using all columns in vehicles table and then use the models to handle the differences, But i had problems setting the fillable fields for the child models...
Then I read about polymorphic relations and it seems the right way to go.
So, my questions are: Which approach is the best? What is the best way to implement it?
Thanks!
Create additional tables:
vehicles_types to store types, like cars, bikes etc.
vehicles_attributes to store specific type attributes related via vehicle_type_id with fields vehicle_type_id, name, value.
I extend other models occasionally, and it works as expected. The migrations need to be set up separately, but the class logic (attributes and methods) will work in the normal OOP way. If you're familiar with this, just do what you're doing!
To explain myself better: the examples on Laravel.com showcase a relation of comments belonging to both videos and posts. However I'm talking about specification: not belonging to, but being a specification of the parent table. (Subtyping) Is using Laravel's Polymorphic Relations still the best approach?
A very basic (and potentially bad) example.
Interesting question.
It is entirely possible to do what you require, with the polymorphic relation that Laravel provides. You however, are referring to table inheritance which is whole other kettle of fish.
You could have your Animal model have a polymorphic relationship that can either be Fish or Mamal, or you could have Fish and Mamal belong to an Animal, and create a pass-through model.
It really depends exactly on how you'll be using this. Will you be going through Animal as in querying the animals table, or will you be going from the children?
In the Doctrine manual, under Constrain relationships as much as possible, it gives the advice "Eliminate nonessential associations" and "avoid bidirectional associations if possible". I don't understand what criteria would make an association "essential".
I say this because it seems that you would often want to go from the One side of a One-to-Many association rather than from the Many side. For example, I would want to get all of a User's active PhoneNumbers, rather than get all active PhoneNumbers and their associated User. This becomes more important when you have to traverse multiple One-to-Many relations, e.g. if you wanted to see all Users with a MissedCall from the last two days (MissedCall->PhoneNumber->User).
This is how the simple case would look with an inverse association:
SELECT * FROM User u
LEFT JOIN u.PhoneNumbers p WITH p.active
It would make it more sensible if there were a way to go across a given relation in the opposite direction in DQL, like the following raw SQL:
SELECT * FROM User u
LEFT JOIN PhoneNumber p ON p.User_id = u.id AND p.active
Can someone explain why they give this advice, and in what cases it would be worth ignoring?
-- Edit --
If there are mitigating factors or other workarounds, please give me simple example code or a link.
I do not see any way to traverse a relation's inverse when that inverse is not defined, so I'm going to assume that building custom DQL is not in fact a solution -- there are some joins that are trivial with SQL that are impossible with DQL, and hydration probably wouldn't work anyway. This is why I don't understand why adding inverse relations is a bad idea.
Using Doctrine, I only define relationships when they're needed. This means that all of the relationships defined are actually used in the codebase.
For projects with a large team working on different areas of the project, not everyone will be accustomed to Doctrine, it's current configuration, and eager/lazy loading relationships. If you define bi-directional relationships where they aren't essential and possibly don't make sense, it could potentially lead to extra queries for data that:
may not be used
may have been selected previously
Defining only essential relationships will allow you greater control over how you and your team traverse through your data and reduce extra or overly large queries
Updated 22/08/2011
By essential relationships, I mean the ones you use. It doesn't make sense to define a relationship you wouldn't use. For example:
\Entity\Post has a defined relationship to both \Entity\User and \Entity\Comment
Use $post->user to get author
Use $post->comments to get all comments
\Entity\User has a defined relationship to both \Entity\Post and \Entity\Comment
Use $user->posts to get all user posts
Use $user->comments to get all user comments
\Entity\Comment only has a relationship to \Entity\User
Use $comment->user to get author
Cannot use $comment->post as I don't retrieve the post it belongs to in my application
I wouldn't think of them as "Inverse" relationships. Think of them as "Bi-directional", if using the data in both directions makes sense. If it doesn't make sense, or you wouldn't use the data that way around, don't define it.
I hope this makes sense
I think this is a great question, and am looking forward to others' answers.
Generally, I've interpreted the advice you cited in the down to the following rule of thumb:
If I don't need to access the (inverse) association inside my entity, then I typically make it unidirectional. In your example of users and (missed) calls, I'd probably keep it unidirectional, and let some service class or repository handle putting together custom DQL for the odd occurrence when I needed to get a list of all users with recent missed calls. That's a case I'd consider exceptional -- most of the time, I'm just interested in a particular user's calls, so the unidirectional relationship works (at least until I've got so many records that I feel the need to optimize).