I have just started using the OpenAccess ORM Visual Designer context. I have never used any previous iteration of OpenAccess. Therefore, when looking at ANY documentation (CHM, forums, code library, wherever...) it is not clear what documentation is for what method (at least not for somebody just trying to get the hang of it for the first time).
The API documentation is the worst offender. I just really have no idea what is and isn't available for my situation.
Just for example...
I was trying to read up on how one might go about tracking individual field/property changes when a .SaveChanges occurs (or any other time might also be ok if an event fires at some other point). So, if I wanted to log those fields that changed and their values, how would I do it. I didn't see anything obvious with the OpenAccessContext (or BASE) classes. Yes, I see how I might get a list of RECORDS that changed, but not what fields within those records changed. Baffled, I just started poking around in the API documentation and came across ITrackingInterface.
Can I use that somehow with my OpenAccessContext (Visual Designer)??
If not, what (if anything) can I use for the same purpose??...and how would I know from looking at any of the documentation that I couldn't use it???
Thanks for any insight you can provide...
16 Answers, 1 is accepted
The Tracking API functionality has not yet been exposed with the new OpenAccessContext as it goes to a re-design phase. We are very sorry for the inconvenience caused at the moment but we will make sure that this functionality is available after the Q2 release(probably for the first service pack). At the moment tracking is available only if you use the old API and work with IObjectScope and the ITracking interface. However that should not stop you from using the visual designer as you are actually able to obtain a scope through the context object. You can achieve this by following these steps:
- Create a partial class for the generated context class.
- Create a method that returns an IObjectScope for example GetObjectScope()
- In this method you should call this.GetScope() to obtain the internal IObjectScope and expose it for your application(GetScope() is a protected method for the OpenAccessContext so this is the reason for this implementation).
the Telerik team
Any word on current or upcoming API changes for the domain context to make life easier for tracking field level changes? Would be pretty nice if there was a handy-dandy way to retrieve that info just like there is to find out what records are being updated/inserted/deleted... seems like the next logical step to provide that info right in that same object somewhere. Can we expect that anytime soon? Thanks!
Exactly, this is the next step we will take into improving the OpenAccess API. Completely new change-tracking API will be provided which will allow the user to plug into the insert/update/delete procedures of the persistent objects and a lot more flexible goodies. However I can not promise you a time frame about the development of this functionality as the there will be major re-design of the API from the known ITracking one. However, Q3 2010 is our milestone at the moment.Best wishes,
the Telerik team
This is becoming a super important aspect to our applications. Can you confirm if this is being worked on and when this might be available to us?
I really really don't want to shift gears and come up with an alternate (non-OpenAccess) solution for this if I can reasonably assume it will be available to us with a certain date in mind.
Yes, I must admit you are right, the Q3 milestone was missed for delivering this API. However after a discussion internally in our team after your recent post, we decided to increase the priority for the development of this API as part of the OpenAccessContext API. I would like to give you assurance at the moment that we will deliver the object tracking features for our next release which is Q1 2011. In terms of time-frame, it usually happens in the beginning of March. I hope that this does not prevent you to develop your projects with data-access based on OpenAccess. We appreciate your patience and collaboration on this issue.Regards,
the Telerik team
I am an "old" telerik customer and OpenAccess user. I am just doing my first project with the new Domain Model and the Visual Designer.
For the purpose of supporting a high priority of this issue, I want to tell you and your team that I am actually rather shocked to discover (after wasting so much time poking around everywhere for information) that this tracking functionality is not implemented yet in the new Domain Model. I mean, any professional n-tier application with business logic will try to hook into a persistent objects insert/update/delete events.
I would like to suggest that the new API will also provide an event for a persistent object being instantiated when it has been read from the data store, like a hook into the class constructor.
I would really like to know what is your motivation for the last requested item? Why do you need an event which notifies you when the a hollow object shell is instantiated? Also because you said you are an old customer of ours I would really like to hear what do you believe we can improve in a tracking API (you have experienced already our old API). My goal is to understand what (if any) changes should we make to the tracking API in order to increase usability. Thanks in advance.
the Telerik team
Please tell me I missed the note in the release notes, or that it just wasn't mentioned, but is in fact part of the 2011 Q1 release. Whatever you do, please don't tell me that it is scheduled for the following quarter release.
We are not satisfied with what we have currently as an API and we are now into the design phase (not only the object state tracking API but also various other notification mechanisms that we have). I will not say again it will be available in the next Q iteration as on our list we have again lots and lots of really important items as well, and I cannot make such a commitment at this very moment.
All the best,
the Telerik team
I guess my frustration (and I'm sure others as well) is that what I am asking for here is not really a "nice to have". As Mikael said, for a professional application this concept is a MUST have. I can live without a visual tuning profiler. I didn't need the visual design wizards completely changed every release (which now I have to learn how the news ones flow). What I need to know is what fields/values changed on a record. It would seem that this is about as basic a concept for an ORM as there is, but yet...here we are without it with the flagship "domain model" context.
I now have to take on the painstaking effort to code this myself manually...which really lowers the value of actually using OpenAccess.
Of all the things the ORM is capable of...and all the changes that are being made... I just cannot believe that a simple "GetChanges" method can't be stuffed in the API in a matter of hours to retrieve the changes in some defined structure. I don't care if it is perfect... just like all the wizards that change every release, you can improve as you go, but get me this simple/BASIC piece of information.
What do you exactly want to achieve? You can get all dirty instances by adding this to your context class:
the Telerik team
Also, I am not using anything with the old "scope" context. I am using the new domain context. So, for example, on the domain context in my application code there is a "GetChanges" method. However, that "GetChanges" doesn't actually get field level changes. That is what we need.
I understand your requirement and again, I apologize for the inconvenience this is causing you. There is simply no API on the context level that would serve your needs at the moment, but we do know the importance of having such API and we are working on providing it as soon as possible. It eventually took us a lot longer than expected as we are thriving to create an API that is much more advanced and gives more control to the customers from the ITracking API that was available on the IObjectScope level. At the same time, we are also doing our best to achieve no performance penalty with this new tracking API while giving control to the user to plug into any CRUD operation on the OpenAccess persistent objects.Best wishes,
the Telerik team
I certainly didn't see anything in the release notes about it.
Although... I did see this:
"Tracking: Changed and Changing event arguments now contain old values. - The changing and changed callbacks of the tracking implementation now contain the old values.
The ChangeEventArgs class now has a WasLoaded property that indicates whether the OldValue property contains real data."
I can only assume this has something to do with the OLD API? If so, one has to wonder WHY IN THE WORLD is the "OLD API" being changed/enhanced, but the flagship "NEW API" (domain context) goes on withOUT any form of change tracking?? It is really baffling.
It took me 15 min to read the list of fixes/changes/additions in this 2011 Q3 release. About 97% was useless to me personally. All those things... and we still have no ability with the new context API to figure out what changed on an update.
It is now about 1.5 years since I was told ("it's coming soon")... I'm guessing it will be one amazing API when it does come out to have had (what will be) 2+ years of development into it (eyes rolling).
I see that there are a lot of changes with the new Context API for 2012 Q1.
I see there is a "GetState" method.
I see new events:
Events - returns an IContextEvents object representing the associated change tracking instance. Via the IContextEvents object, you could attach to the following events:
- Added - occurs after an object was marked as to be persisted by the object context.
- Adding - occurs before a persistent object is added to the object context.
- Changed - occurs after a field of a persistent object has been changed by the application.
- Changing - occurs before a field of a persistent object is changed by the application.
- Refreshed - occurs after a persistent object is refreshed from the database.
- Refreshing - occurs before a persistent object is refreshed from the database.
- Removed - occurs after a persistent object was marked as to be removed from the object context.
- Removing - occurs before a persistent object is removed from the object context.
I don't see any other details regarding these things.
Is this the new domain Context things/events that I would use to implement a Change Tracking mechinism??
If so, are there any other details around (examples etc...) that I could see. I was in the 2012 Q1 release webinar and searched forums and this is all the info I can dig up. I would love to implement this (as well as others I'm sure since we have waited quite some time), so any guidence on the "NEW' way to use these things would be apprecicated.
We have recently released a new section of our documentation that presents the entire Context API with some sample code demonstrating the usage of the functionality. You can find it here. You can find there several articles for tracking changes - I hope they will help you get started.
Do not hesitate to contact us if you have any remarks, suggestions or further questions.
the Telerik team