Is there an equivalent to Rails-like polymorphic associations in Doctrine? I'm trying to do something similar to: http://railscasts.com/episodes/154-polymorphic-association
Yes, sort of. Inheritance. I am currently using concrete and column aggregation on a project at work, but it's not as powerful as polymorphic associations.
More info here.
Related
I have a problem where there are courses that have classes with different days. However, I also have the possible days of having classes. Using Spring Data, I created the Class, DayHour and PossibleDaysClass entities. Using the ORM approach, I would have to create a table to "query" between DayHour and PossibleDaysClass entities. In this case, the question arose of, when to use the entities approach and #JoinTable and when to decide to use an approach as a native query?
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)
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?
I have three models:
Task
Project
Topic
A Task can be associated with a Project or a Topic or to both.
Is there any type of eloquent relationship that I can use to achieve this type of relation or do I have to use the Polymorphic Many to Many?
I don't want to use the standard belongsTo with foreign key because I might extend it to other models.
Thanks!
Eloquent Polymorphic relations docs defines a "type" column so your single Task could not belong to two models at once. That mean, Task can morph to Topic OR Project.
A way to solve problem you answered yourself - belongsTo, hasOne, hasMany and so on.
I am currently learning Laravel, and I have a query regarding the best practice for creating entity relationships whilst writing a migration as I am confused as to how best do this.
Lets say you are writing an entity schema that you know will have a Many to Many relationship or a One to Many relationship or even a foreign key, etc.
Are you meant to code the relationship into the migration itself, or after it?
All the tutorials I've seen up to now seem to gloss over how to make the migration know that Entity A will have relationship with Entity B and put the relationships in the models using hasMany(), etc
This confuses me, are you meant to put the relationship structure into the migration; or is it better to create your migration and then make your relationship in the model?
Thanks now