[RELATIONSHIPS] Duplicate records with related relationships

[atlasphp]

[RELATIONSHIPS] Duplicate records with related relationships

[pmjones]

Hi @allanbarbosa -- are you still having this problem?

[allanbarbosa]

Yes, still doesn't work.

[pmjones]

Sorry for the trouble. Can you post some of the code, so I can look more deeply into what's going on, and maybe try to figure out what the problem is?

[scipilot]

I think I've seen this same problem and found it's because there is no explicit/surrogate primary key in the relation table - I don't think Atlas supports it. (But I only have two days' experience - and I'm currently trialling v1 as I'm stuck with PHP v5.6 for a particular site.)

I have a relational table in a CMS which has no primary key. It has two ID foreign-key columns, one for content type A, one for content type B and some other metadata columns about the relation (polymorphism, ordering, groups etc). This is similar to the credit_movement_attachment table, but with extra info.

I couldn't see a way to specifically utilise a relation table, so I thought I'd do it in two steps, and defined it as a data source table itself, and related content type A to it as one-to-many. I then created a second one-to-one relation from this dummy relation type to the content type B, but that part is not involved in the problem.

In a sample dataset, there are 12 content type A's and 35 relations from various instances of A. I found when selecting all 12 content type A's with the relation type, it returns 35 relations, but they are all exactly the same record - the first one duplicated, and therefore they all get assigned to the single matching instance of content type A.

After stepping through the code, I see the line in \Atlas\Orm\Table\AbstractTable::getSelectedRow cannot calcIdentity so it returns the same row again. According to the comment this is because it's "mapped already", which I'm not quite clear on.

I added a surrogate primary key to the relation table with auto-increment, and it immediately fixed it. The 35 relations are now assigned (stitched) to their appropriate content type A records.

I know this is an ancient ticket, but I suspect if you add a surrogate primary key to credit_movement_attachment the two Attachment records you describe will find their appropriate homes again.

I'm not a fan of surrogate keys, but I couldn't see a way of using a compound key in the remote table, because the two FK ID columns aren't from the same referring table. It seems although Atlas supports composite keys (which is great), both have to come from table-A and be in the related table too. For me I've got like: A.id => R.A_id,R.B_id => B.id, so table R is unique on [A_id,B_id] but I can't define that in A's mapper?

Anyway, I'm not raising a bug report myself, just thought I might have the cause of this one. I've enjoyed trialling Atlas so far - this is the only major hurdle I've hit. I guess I can live with the shame of the extra key.