Opf3 Forum: Identity Map question

RE: Identity Map question

Wed, 20 Aug 2008 6:12:58 PM GMT

OMG. I completely forgot about doing that. I will update that in the next days. Until then you could use the one that comes with the download

RE: Identity Map question

Wed, 20 Aug 2008 5:24:18 PM GMT

Thanks again for the info. I've been taking a look at the new XmlTypeMappingProvider and it looks great! It should make it alot easier to migrate some of my older applications to opf3.

Do you have any plans on updating the online documentation?

RE: Identity Map question

Wed, 20 Aug 2008 3:40:44 PM GMT

Hi Al,

I know! Opf3 has been designed to be very open to add new query languages and storages. That was one of the main goals. You could use Opf3 to query and kind of storage that is not limited to ADO.NET, actually.

That has pros and cons. Pros are that Opf3 is very flexible when it comes to add new storages to the framework. And that you can extend it to any query language that you want and your storage understands. Cons are that you can extend it to any query language tha your sotrage understands but Opf3 doesn't...

Therefore the IdentityMap is really only here to make sure you never have two objects in memory that represent the same row in the database.

As said: caching might help you to reduce your roundtrips a lot. If caching would fail and the IdentityMap is enabled you would be sure to only have the same object once in memory :)

Christian

RE: Identity Map question

Wed, 20 Aug 2008 2:22:07 PM GMT

Thanks for all the information on what's being done internally - the more the functionality is understood the better decisions we can make determining it's for different scenarios.

Al

RE: Identity Map question

Wed, 20 Aug 2008 1:50:14 AM GMT

Well it works as this: Opf3 gets a IQuery and asks the command builder to translate this thing somehow into a query that is compatible with the current storage. They do that and Opf3 executes it. Opf3 doesn't know anything about how the query was transformed or what it might contain...

After that the results come back and the objects are populated with the data. From these objects the primary key is taken to check if that one is already in the identity map. If that is true then Opf3 will take the object from the identity map. If that is false the object will be added to the identity map and that one will be returned.

So what is the identity map for? It is in Opf3 to make sure that you always deal with one object in memory. You shouldn't be able to have an object that is represented as one row in the database, represented by different instances in memory.

If you really want to work around loading stuff you should check out the caching features that are build in Opf3. There you could limit yourself to only parse certain queries type and use them understand beforehand if an object should be loaded or not...

Actually if Opf3 would try to understand somehow how the query works it would probably take longer than loading the objects itself from the database.

RE: Identity Map question

Tue, 19 Aug 2008 4:53:23 PM GMT

Christian Liensberger wrote:
You are right. But in the case of Opf3 where you can use whatever query language you want it is really really hard to understand if the object that is in the identity map would be reloaded or not. Therefore what Opf3 does is understanding what has been loaded (analyzing the vector) and deciding whether to use the instance in the identity map or the one that is fresh and comes from the database.

So far only the primary keys are used to understand if the object is the same. They are the identifier in the table and therefore they are taken into consideration.

Christian

Okay, So if the various ways of loading were all removed then it could be done. Of course then you would have very upset folks... When you you say

Christian Liensberger wrote:
So far only the primary keys are used to understand if the object is the same. They are the identifier in the table and therefore they are taken into consideration.

What is being considered?

RE: Identity Map question

Tue, 19 Aug 2008 4:20:26 PM GMT

You are right. But in the case of Opf3 where you can use whatever query language you want it is really really hard to understand if the object that is in the identity map would be reloaded or not. Therefore what Opf3 does is understanding what has been loaded (analyzing the vector) and deciding whether to use the instance in the identity map or the one that is fresh and comes from the database.

So far only the primary keys are used to understand if the object is the same. They are the identifier in the table and therefore they are taken into consideration.

Christian

RE: Identity Map question

Tue, 19 Aug 2008 2:45:55 PM GMT

But isn't the goal of the IdentityMap to reduce trips to the db by checking to see if the object is already loaded and return it? I can certainly see a benefit to ensuring you are always looking at the latest copy but I thought that was the trade-off for less database hits?

I could see lots of questions on this.What type of check is done? Checksum or a property by property? If I've changed a value of an object and the object is reloaded with different values - what is returned?

I realize that these issues are things that would have to be dealt with in all systems. But I thought the main benefit of the IdentityMap was that it dealt with these problems by saying - I'll deal with concurrency only on updates/deletes of data only.

-Al

RE: Identity Map question

Tue, 19 Aug 2008 1:20:22 AM GMT

Hi Alfred,

right now Opf3 will still go and call the database. The checking if it is the same object happens only in memory. That is done because it is literally impossible to do it with random queries. In Opf3 everything that implements IQuery could fire a query to a storage...

I hope you understand that.

Chris

Identity Map question

Tue, 19 Aug 2008 12:36:56 AM GMT

Below is a snippet of a simple test I did to use the new IdentityMap feature, which isn't working for me - although it's highly possible it's user error!

//Code to create context removed....(regulare context w/ md5 concurrency....

  //Since it's not enabled by default
  context.IdentityMap.Enabled = true;

//Get every widget with an id greater than 1
ObjectSet widgets = context.GetObjectSet("ID>{0}",1);

//Get the first widget which will require a trip to the database.
Widget w1 = context.GetObject("ID={0}",1);

//Get another instance of the first widget which should not have to be retrieved
//from the database since it's in memory now.
Widget w2 = context.GetObject("ID={0}",1);

So when I look in the sql profiler I expect 2 calls to the db. One for the Objectset with the greater than. The second for w1. I am still getting a call to the db for w2 however even though it should be in the IdentityMap shouldn't it?