We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.
  1. Home
  2. ORM

Multiple field relationships example is muddled

We've been using Phalcon for years and love it, however the database documentation has always been somewhat lacking. I've been looking closer at the current model relationships documentation and had a query about the following example. Putting aside the fact that the Parts model changes its schema part way through the examples, and it would be better to use examples that remain consistent throughout the documentation, the following snippet of a multiple fields scenario seems confusing and problematic.

 $this->hasOne(
        ['id', 'type'],
        Parts::class,
        ['robotId', 'robotType'],
        [
            'reusable' => true, // cache related data
            'alias'    => 'parts',
        ]
    );

First, robotType is described as being "Mechanical etc." and I wonder what the etc. might mean in practice because could it really be anything else. Next, Robots id is unique, therefore the robot type for a given robot is unique. Why would the (now redefined) Parts model need a robotType field given that it has the robotId field? We can obtain the robotType for a part from the related robot record, and with a suitable index there would be no performance issue from the join to do that. Replicating the robotType between robot and parts is also problematic because should the type of a robot be changed, the parts would need to be updated too, so I don't understand the thinking behand this example.

Can someone explain the example better and say why it is like it is, why there is the duplicate robot type etc.



8.4k

Parts can have multiple records for the same Robot but only one type for each Robot therefore multiple field is required in this case

If you alter a belongsTo() relationship to act as foreign key, it will validate that the values inserted/updated on those fields have a valid value on the referenced model. Similarly, if a hasMany()/hasOne() is altered it will validate that the records cannot be deleted if that record is used on a referenced model.



896
in reply to talal424

Parts can have multiple records for the same Robot but only one type for each Robot therefore multiple field is required in this case

Is the meaning of type in the Parts table different to that of the robots table? So while we might have Mechanical as a type in the Robots table, we might have Base, Brick, Wheel etc. for type in the Parts table. I thought there was a one to one mapping between columns in each table, and therefore they have the same meaning, so assumed that's not the case. Or, are the values for type in the parts table the same as those in the robots table?

I'm wondering what type of question does this schema solve? If there wasn't a type column on parts, we could still find all the parts for a given robot, and we could also find all parts that belonged to robots of a given type. If type on parts was Base, Brick etc. as described above, we could do queries such as find all the brick parts for a given robots, or find all the brick parts for all mechanical robots, still without the multicolumn setup.



896

Further, let's imagine that we have Mechanical and Electronic robots, and robot id is only unique for robots of a given type. The multicolumn mapping would perhaps address that issue, allowing the tuple of robot id and type to be the key, but the correct solution would be to introduce a unique id in robots that while not having any business meaning would give a single unique identifier, again eliminating the multicolumn issue.



8.4k

i'm with you on how the examples are written sometimes its confusing but its about how can use them

as you said we can use belongsTo by using only the primary key in the example they provided but it shows how we can implement multiple field relations