I have multiple models which can and can be followed by each other i.e. Business, Agency, Vendor, User.
The schema of the above scenario is as follows:
id follower_id follower_type followable_id followable_type
Is there any relationship for the above case in Laravel? How can I create relationship and use eloquent methods?
Related
In Laravel it is possible to use the hasMany() and belongsTo() methods in the Model to specify the relation between tables. This for one-to-many relations.
However in the migration files, this relation is also specified for the database by the
$table->foreign('userId')->references('id')->on('users')
Why does it to be specified double in Laravel?
Why does Laravel doesn't fetch the relationship from the database, and do we have to specify it double?
Laravel offers hasMany() and belongsTo() etc for quicker access to parent/child records between tables on the model level. For instance, you may access the child record with ->{attr}, which makes the child record as if an attribute of the parent record.
It also comes with other benefits, such as eager loading of child record by providing the relationship parameter into ->with() function.
In comparison, the usage of relation in migration files are to enforce relationship between tables on database level.
Is it okay to use a polymorphic relation when there are lets say 6 common columns and 2 columns with different names?
I need to track car maintenance and refueling.
maintenances - table
-date
-km_driven
-info (refers to maintenance info )
refuelings - table
-date
-km_driven
-amount (refers to amount in liters)
So, should i use polymorphic relationship or not? Is it ok if there are more different columns per model?
IMHO for your case I will go for single table inheritance (STI), but you need a library like this tightenco/parental or this one Nanigans/single-table-inheritance.
Laravel codebase has no support for STI without an external library. You can try to use polymorphic relation to solve your case but you will end up with 3 different tables. I think you want to use a single table with two or even three models so my advice is to try one of the STI library above.
STI is appropriate when your models have shared data/state. Shared behavior is optional because can be defined per Model. An example could be different type of vehicle Models: Car, Truck, Bike etc..
With Polymorphic Relations instead, a model can belong_to several models with a single association. This is useful when several models do not have a relationship or share data with each other, but have a relationship with the polymorphic class. An example could be the Comment Model that can belongs to other Models: User, Post, Image etc..
I am trying to build a simple Laravel application. My data model looks like the following:
ENTITIES:
Project, Requirements, ProjectRequirementStatus
RELATIONSHIPS:
A Project has many Requirements
A requirement belongs to many Projects as a "ProjectRequirement"
A "ProjectRequirement" has one ProjectRequirementStatus
A ProjectRequirementStatus belongs to many Projects
TABLES:
projects
requirements
project_requirements
project_requirement_statuses
MODELS:
Project, Requirements, ProjectRequirementStatus
My question IS:
Is it improper to create a model for a relationship class? In this case, I would need to create a ProjectRequirement model and define the relationship to the ProjectRequirementStatus class.
I'm confused because most of my pivot tables include IDs of the two tables they are joining in a Many to Many, and typically, no additional relationships.
Am I thinking about this the wrong way? Are there "best practices" in terms of when a Model is created versus when it's not needed?
Using the 3NF in Laravel, you do not have to make models for the relationships. Laravel provides the Eloquent ORM which will provide the relationships without having to make the pivot tables models.
The Eloquent ORM also provides you a way to access data on pivot tables. (Defining The Inverse Of The Relationship)
Let's say I have two tables:
Users: id, name, country_id
Countries: id, name
Of course each user can only have one country, but each country is assigned to multiple users.
So would it be safe to have a User model that utilizes hasOne and a Country model that uses belongsToMany method?
Documentation makes it seem like you can't mix and match different types of relationships.
What you are describing is actually a One To Many relationship, where one country has many users. Your Country model should utilize a hasMany relationship, while your user would have a belongsTo relationship.
#Andy has already answered well.
Anyway, my advice is to always think in the following way to create a One-To-One, One-To-Many, or a Many-To-Many relationship:
In the table with the foreign key (if any) use belongsTo
In the other table without the foreign key use hasOne or hasMany
In any of them have a foreign key, you have a Many To Many relationship and you must use belongsToMany in both of them (you need the pivot table, of course).
Laravel 4.1 introduced the hasManyThrough relationship. This assumes 2 relating hasMany relationships. I however would like to retrieve the hasMany relationships of a belongsTo relationship instead.
Project (id, contact_id, ...)
Contact (id, ...)
Address (id, contact_id, ...)
For each project, I would like to get all addresses.
I managed to do this using a belongsTo() relationship and some additional table joining. However, a belongsTo relationship binds a single object, instead of an array.
So my thoughts are I either need to:
... be able to override the LIMIT 1 behavior on belongsTo relationships
... or be able to override the hasManyThrough to work with a belongsTo as intermediate relationship.
It sounds like you are trying to set up a many-to-many relationship between Projects and Contacts, with a one-to-one relationship between Address and Contact. If that is the case you will need to create a pivot table "project_contact" with columns "project_id" and "contact_id" as well as any other columns (timestamps(), etc). Then you can set a "belongsToMany('Project')" relationship on the Contacts.
I'm not sure if that is what you're after, but it solves the problem as I understand it.