SyncFKFields problem

Posts   
 
    
mikeg22
User
Posts: 411
Joined: 30-Jun-2005
# Posted on: 31-Aug-2007 07:03:52   

There is a block of code I would like to run every time a field value changes. PostFieldValueSetAction is perfect for when fields are directly set, but this is not called when SyncFKFields happens after an entity reference property of an entity changes...OnPropertyChanged is called, but this is only called for the last fkField in the relation, and overriding OnPropertyChanged in CommonEntityBase will just tell me that a "property" changed, not a field, and I would have to spend a lot of processing in order to find out of if the propertyName is a real field or not.

So, 2 questions I guess: 1. Why isn't SetValue called in SyncFKFields? Without this, ValidateValue and PostFieldValueSetAction are never called even though a field value has changed.

  1. OnPropertyChanged is called, but why only for one of the fk fields in the relation?

The reason this is important to me is that I need to assert some business rules when an entity reference is changed, but there doesn't seem to be a natural place to hook into this.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39910
Joined: 17-Aug-2003
# Posted on: 31-Aug-2007 11:28:07   

mikeg22 wrote:

There is a block of code I would like to run every time a field value changes. PostFieldValueSetAction is perfect for when fields are directly set, but this is not called when SyncFKFields happens after an entity reference property of an entity changes...OnPropertyChanged is called, but this is only called for the last fkField in the relation, and overriding OnPropertyChanged in CommonEntityBase will just tell me that a "property" changed, not a field, and I would have to spend a lot of processing in order to find out of if the propertyName is a real field or not.

So, 2 questions I guess: 1. Why isn't SetValue called in SyncFKFields? Without this, ValidateValue and PostFieldValueSetAction are never called even though a field value has changed.

This is by design. The reason is that the FK sync should be automatic and without validation and above all: without value conversion (which is also possible in that pipeline). After all: the sole purpose of this action is to set the FK field with the exact same value as the PK field. If validation would happen, it might be the validation would reject the value and the save would probably terminate. It's not a big deal, read on simple_smile

  1. OnPropertyChanged is called, but why only for one of the fk fields in the relation?

The reason this is important to me is that I need to assert some business rules when an entity reference is changed, but there doesn't seem to be a natural place to hook into this.

There is a facility for this purpose simple_smile -> OnRelatedEntitySet and OnRelatedEntityUnset simple_smile these methods are called when a related entity is set/unset. You can use them to run business logic when a related entity is set. You can override them in a partial class of the entity, they're protected virtual and empty by default.

Frans Bouma | Lead developer LLBLGen Pro
mikeg22
User
Posts: 411
Joined: 30-Jun-2005
# Posted on: 31-Aug-2007 16:30:17   

Otis wrote:

mikeg22 wrote:

There is a block of code I would like to run every time a field value changes. PostFieldValueSetAction is perfect for when fields are directly set, but this is not called when SyncFKFields happens after an entity reference property of an entity changes...OnPropertyChanged is called, but this is only called for the last fkField in the relation, and overriding OnPropertyChanged in CommonEntityBase will just tell me that a "property" changed, not a field, and I would have to spend a lot of processing in order to find out of if the propertyName is a real field or not.

So, 2 questions I guess: 1. Why isn't SetValue called in SyncFKFields? Without this, ValidateValue and PostFieldValueSetAction are never called even though a field value has changed.

This is by design. The reason is that the FK sync should be automatic and without validation and above all: without value conversion (which is also possible in that pipeline). After all: the sole purpose of this action is to set the FK field with the exact same value as the PK field. If validation would happen, it might be the validation would reject the value and the save would probably terminate. It's not a big deal, read on simple_smile

  1. OnPropertyChanged is called, but why only for one of the fk fields in the relation?

The reason this is important to me is that I need to assert some business rules when an entity reference is changed, but there doesn't seem to be a natural place to hook into this.

There is a facility for this purpose simple_smile -> OnRelatedEntitySet and OnRelatedEntityUnset simple_smile these methods are called when a related entity is set/unset. You can use them to run business logic when a related entity is set. You can override them in a partial class of the entity, they're protected virtual and empty by default.

Missed that one...I knew there had to be something in there to do this, I just didn't see it! simple_smile

But still, why is OnPropertyChanged called for just one of the synced Fk fields?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39910
Joined: 17-Aug-2003
# Posted on: 31-Aug-2007 17:33:45   

Hmm, that's a good one... I think that's an oversight. in many cases not a problem, as the entity itself is flagged as changed so only in rare databinding scenario's this will be noticed (I've never seen a report this was a problem), though if you bind to the event to execute code as a follow up on change, it is indeed wrong.

I'm not sure if changing this is breaking applications or not...

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39910
Joined: 17-Aug-2003
# Posted on: 04-Sep-2007 11:16:09   

I've filed a v2.6 api change for this (as multiple events could break current apps) so instead of 1, all fk field's events are raised.

Frans Bouma | Lead developer LLBLGen Pro