This question is locked. New answers and comments are not allowed.
Hi.
OA supports persistence by reachability, which is great. However, I found out that tracking does not work properly (or at least as I expected) when adding objects.
Example:
If i add a persistent object A with a reference to persistent object B to an object scope and commit transaction, both A and B are stored in the database, great! But only object A fires the ITracking.Added event.
Arguably, this may be correct behaviour since object B was never actually added to the object scope, but still it was added to the datastore by "reachability", and tracking should be able to pick this up, no?
Enyhow, this is very important, since i need to know (for audit and synchronization) which objects have been added to the datastore.
Please, please, please, tell me I'm right?!
Best Regards
Pål Økern
OA supports persistence by reachability, which is great. However, I found out that tracking does not work properly (or at least as I expected) when adding objects.
Example:
If i add a persistent object A with a reference to persistent object B to an object scope and commit transaction, both A and B are stored in the database, great! But only object A fires the ITracking.Added event.
Arguably, this may be correct behaviour since object B was never actually added to the object scope, but still it was added to the datastore by "reachability", and tracking should be able to pick this up, no?
Enyhow, this is very important, since i need to know (for audit and synchronization) which objects have been added to the datastore.
Please, please, please, tell me I'm right?!
Best Regards
Pål Økern
2 Answers, 1 is accepted
0
Hi Pål,
From you perspective you are right, but it is more complicated.
The B object is not really added to the database. If you add A and remove the a->b connection after that the b object is not persisted, only if you call scope.Add(b) you can be sure that b get's store. We name this state 'provisional persistence'.
There are the IInstanceCallbacks which you have to implement at each of your persistent classes to get the PreStore function called. This function is called for all new and dirty objects inside the commit call.
If you make a non persistent base class for all your persistent classes you can implement the interface there and fire your own event.
Greetings,
Jan Blessenohl
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
From you perspective you are right, but it is more complicated.
The B object is not really added to the database. If you add A and remove the a->b connection after that the b object is not persisted, only if you call scope.Add(b) you can be sure that b get's store. We name this state 'provisional persistence'.
There are the IInstanceCallbacks which you have to implement at each of your persistent classes to get the PreStore function called. This function is called for all new and dirty objects inside the commit call.
If you make a non persistent base class for all your persistent classes you can implement the interface there and fire your own event.
Greetings,
Jan Blessenohl
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
Pål
Top achievements
Rank 1
Rank 1
answered on 14 Jan 2009, 03:11 PM
Excellent!
Thank you very much.
Pål
Thank you very much.
Pål