Please don't ask me to explain why this came up. It would take about 100 pages.

If I have a 1:1 relation between two entities and fetch them both, using a prefetch.

Entity1 has a reference to entity2, which has a reference to entity1, etc. I assume this is by design?

Is there any way of determining the direction in which the fetch occurred? In other words, which was the original "parent" entity and which was the "child"?

Hopefully this question makes sense.

Thanks,

Phil

Well if they each have a reference to each other then there really isn't a parent. You can always just fetch either as your first and then define the other using the prefetch. Why does it matter which you chose first? Maybe if you explain the context you are using it we may be able to give you a better answer.

1:1 relations are a difficult thing: it's not obvious which side is the PK side and which is the FK side, unless one side is a PK and the other side isn't.

in relational databases, there's no such thing as 'parent' and 'child', just relationships. So if two entities have a 1:1 relationship, there's no parent/child, but a 1:1 relationship.

A 1:1 relation (ship) is present if: 1) all fields in the relation form the full PK on both sides 2) the FK side isn't a PK (or not the full PK) but has a UC.

A 1:1 B obviously makes A reference B and B reference A.

It isn't determinable in generated code which side is the PK in the case of 1). You can check the fields in the relation object and check if they're an FK, but that fails in A 1:1 B 1:1 C (where B is the PK side for B - C but also an FK.

if you absolutely needed to know, could you use the designer to create a custom property on the implied primary entity?

Otis wrote:

1:1 relations are a difficult thing: it's not obvious which side is the PK side and which is the FK side, unless one side is a PK and the other side isn't.

in relational databases, there's no such thing as 'parent' and 'child', just relationships. So if two entities have a 1:1 relationship, there's no parent/child, but a 1:1 relationship.

A 1:1 relation (ship) is present if: 1) all fields in the relation form the full PK on both sides 2) the FK side isn't a PK (or not the full PK) but has a UC.

A 1:1 B obviously makes A reference B and B reference A.

It isn't determinable in generated code which side is the PK in the case of 1). You can check the fields in the relation object and check if they're an FK, but that fails in A 1:1 B 1:1 C (where B is the PK side for B - C but also an FK.

Yep, I understand that from a SQL perspective, there really is no parent and child. I meant more along the lines of the direction in which the entities were fetched (the "parent" being the "higher" entitiy on the graph).

Without going into too much detail, essentially I do some work on entity1, then need to do some work on a related entity2. Independent of that, I sometimes have work to do on entity2, and then need to do some work on the related entity1. These methods are abstracted so that anytime I am doing work on one entity, it does work on the other. This obviously causes a problem as it creates an endless loop. So my thought that was there might be a way to tell in which direction the entities were fetched.

The way it currently works makes sense, and I have a workaround, so it's not a big deal. Thanks for the replies.

Phil