When you try to persist an object Telerik OpenAccess ORM will require an “identity” so that the object is uniquely identified for storage and retrieval. Usually this id is mapped directly to a primary key column or columns (composite key) in the database and identifies also the in-memory representation of the object. Using this identifier, you can directly retrieve the object from the database.
Supposing that we have table with an int primary key (for example the Category table from the Northwind database) and we want to retrieve the Category with id that is equal to 6 directly. We would need just those simple lines of code:
You can do the same for any type of primary key. Here is an example for the Customer table where varchar is used for primary key:
As you can see from the above example – creating object identifiers is easy. You can do so by parsing a string representation for a given type, by using the Database.OID class method ParseObjectId( typeOf( TargetClassName ), string idString ). For internal identity, you can also pass null as first parameter.
Note that there is a strict format for working with the internal identity. Here is an example:
When it is required to pass the type of the referenced persistent instance along with its keys, you must use the Database.OID.ToString(IObjectId) and Database.OID.FromString(string) method pair to transform between IObjectId and string. This pair does not require that the type is statically known. The Database.OID.GetObjectId(object) method returns the object identity for the passed object. This method is especially useful for getting the object identity when single or multiple field identity is used and the object is not connected. It returns the correct object identity (even for internal identity) in the connected mode as well.
But how does exactly this GetObjectById method works? Here is some insight:
When a call to the GetObjectById is made then Telerik OpenAccess ORM makes an attempt to find any in-memory representation associated with the given persistent object. If there is already an object associated with the passed IObjectId in memory then the method quickly returns this instance without making any trips to the database. If no instance is present the runtime tries to find already loaded data for the given identity. Data of the object can already be present in the scope by having an appropriate fetch plan. When such data is present, the user visible in-memory representation is created from that data and returned to the caller in a “persistent-clean” state.
When the scope does neither has an in-memory representation nor has data prefetched, the second level cache is checked. The second level cache is disabled per default, but if it is enabled, it may contain instance data that can be used to avoid database server calls.
In case where nothing is found on the client for the given object identity, a trip to the database is made and the values for the default fetch group are obtained.
That’s pretty much it. Stay tuned for more information on Telerik OpenAccess ORM.
Subscribe to be the first to get our expert-written articles and tutorials for developers!