Frans, Why do you only call SyncFKFields on entities added to an EntityCollection when the parent Entity is not new (not in the database yet)?

Does this have something to do with fetching primary keys on insert or something?

Why do you only call SyncFKFields on entities added to an EntityCollection when the parent Entity is not new (not in the database yet)?

I assume you meant "when the parent Entity is new".

PKs don't have to be identity colums, so you if you have a new Entity you may have set it's PK in code before saving it.

mikeg22 wrote:

Frans, Why do you only call SyncFKFields on entities added to an EntityCollection when the parent Entity is not new (not in the database yet)?

Does this have something to do with fetching primary keys on insert or something?

Yes. The PK is unknown at that stage, and as the entity isn't defined yet (it's not saved), the PK isn't synced in that state, even though the PK might be a real value and not an identity field.

Otis wrote:

mikeg22 wrote:

Frans, Why do you only call SyncFKFields on entities added to an EntityCollection when the parent Entity is not new (not in the database yet)?

Does this have something to do with fetching primary keys on insert or something?

Yes. The PK is unknown at that stage, and as the entity isn't defined yet (it's not saved), the PK isn't synced in that state, even though the PK might be a real value and not an identity field.

The situation comes up that, when adding the child of a saved entity, the PK for that child is set by synching, but adding a child to that child will not result in a synching. This leads to a strange result in our app where we are depending on foreign keys (and not dependent entities) to show a hierarchal relationship.

In the situation I described above, the PK is known, as it is set in the parent by the synching with the saved grandparent. Could your code be modified to look for this situation (one in which the parent entity actually has a primary key)?

mikeg22 wrote:

Otis wrote:

mikeg22 wrote:

Frans, Why do you only call SyncFKFields on entities added to an EntityCollection when the parent Entity is not new (not in the database yet)?

Does this have something to do with fetching primary keys on insert or something?

Yes. The PK is unknown at that stage, and as the entity isn't defined yet (it's not saved), the PK isn't synced in that state, even though the PK might be a real value and not an identity field.

The situation comes up that, when adding the child of a saved entity, the PK for that child is set by synching, but adding a child to that child will not result in a synching. This leads to a strange result in our app where we are depending on foreign keys (and not dependent entities) to show a hierarchal relationship.

Though it's consistent behavior. I understand it can lead to unexpected results IF you depend on an FK field being set though the sync doesn't take place at that point for reasons stated above.

In the situation I described above, the PK is known, as it is set in the parent by the synching with the saved grandparent. Could your code be modified to look for this situation (one in which the parent entity actually has a primary key)?

No. The following is one of the reasons why: Say your PK is a varchar(10) field. The FK is also a varchar(10). Now, you create a new entity with the pk "Foo". You add a new child entity to that entity and if I'd follow your reasoning, the fk in the child entity would become "Foo" as well.

However, because the parent isn't saved yet, the PK can be changed. So the user discovers it shouldn't be 'Foo' but 'Bar'. What should happen in that case with the FK? I assume you will say: "that should be updated as well". But how is that noticed by the child? Only if it subscribes to events of the parent. The more events are subscribed by childs the more risk there is the child keeps a parent in memory even if the parent is out of scope.

So until the PK is finalized, e.g.: when the entity is actually saved, the PK isn't synchronized with childs.

Now, I'm not completely certain about your last remark, is the FK the PK of the child? (which wasn't clear to me)

Otis wrote:

mikeg22 wrote:

Otis wrote:

mikeg22 wrote:

Frans, Why do you only call SyncFKFields on entities added to an EntityCollection when the parent Entity is not new (not in the database yet)?

Does this have something to do with fetching primary keys on insert or something?

Yes. The PK is unknown at that stage, and as the entity isn't defined yet (it's not saved), the PK isn't synced in that state, even though the PK might be a real value and not an identity field.

The situation comes up that, when adding the child of a saved entity, the PK for that child is set by synching, but adding a child to that child will not result in a synching. This leads to a strange result in our app where we are depending on foreign keys (and not dependent entities) to show a hierarchal relationship.

Though it's consistent behavior. I understand it can lead to unexpected results IF you depend on an FK field being set though the sync doesn't take place at that point for reasons stated above.

In the situation I described above, the PK is known, as it is set in the parent by the synching with the saved grandparent. Could your code be modified to look for this situation (one in which the parent entity actually has a primary key)?

No. The following is one of the reasons why: Say your PK is a varchar(10) field. The FK is also a varchar(10). Now, you create a new entity with the pk "Foo". You add a new child entity to that entity and if I'd follow your reasoning, the fk in the child entity would become "Foo" as well.

However, because the parent isn't saved yet, the PK can be changed. So the user discovers it shouldn't be 'Foo' but 'Bar'. What should happen in that case with the FK? I assume you will say: "that should be updated as well". But how is that noticed by the child? Only if it subscribes to events of the parent. The more events are subscribed by childs the more risk there is the child keeps a parent in memory even if the parent is out of scope.

So until the PK is finalized, e.g.: when the entity is actually saved, the PK isn't synchronized with childs.

Now, I'm not completely certain about your last remark, is the FK the PK of the child? (which wasn't clear to me)

The FK is the PK of the parent. The FK exists in the child entity and points to the parent. I think this is what you are asking but I'm not sure

As for your example, the child entity already subscribes to the parent's AfterSave event, so why couldn't it subscribe to a PKChanged event or something like that? Is the problem just that subscribing to 2 events from the parent leaves more room for error (by not unsubscribing?)

mikeg22 wrote:

Otis wrote:

...

So until the PK is finalized, e.g.: when the entity is actually saved, the PK isn't synchronized with childs.

Now, I'm not completely certain about your last remark, is the FK the PK of the child? (which wasn't clear to me)

The FK is the PK of the parent. The FK exists in the child entity and points to the parent. I think this is what you are asking but I'm not sure

No that's not what I was asking . I meant: Employee with pk ID and Manager with pk ID. Manager's ID is an FK to Employee's ID, so Manager's PK is also an FK.

As for your example, the child entity already subscribes to the parent's AfterSave event, so why couldn't it subscribe to a PKChanged event or something like that? Is the problem just that subscribing to 2 events from the parent leaves more room for error (by not unsubscribing?)

Yes, it leads to more code, as PK's can have multiple fields, plus as the entity is still undefined, the FK shouldn't be set until the PK is defined, when the entity is defined, after the save. Because it can be that the PK is an identity, the FK should be synced afterwards, not beforehand, so you'll get inconsistend behavior: a non-defined PK is synced with its FK fields only if its not an identity field.

The event subscribing isn't the real issue, the non-defined PK is the real issue. Consider: you have a new entity and you add an existing entity as a child to that new entity. The FK in that existing entity changes. It's then dirty. But actually, it shouldn't be, as technically, the entity isn't really changed yet, because the save hasn't taken place. So it's a principle: where is the entity exactly defined, in the db or in memory. LLBLGen Pro builds on the concept that the entity is defined in the db. This means that a new entity doesn't really exist until it's saved succesfully. That's a core concept and thus pre-save synchronization can ONLY take place if the PK is defined with the entity, which is only the case if the entity is saved succesfully.