I've heard in ASP.NET 2.0, the Cache object is so greatly enhanced that you can say something like: NewDataTableDependency("Server.Database.dbo.Employee")? This is going to be a bomb ans solve all our problems regarding O/R mapper caching strategy. Who can
confirm this? We can even let a single object depend on the table. What the hell, say it's invalidated too early, so what? 95% of the time, the underlying tables won't change.
I've also heard something like this. However, you have to figure it is a SQL 2000 / Yukon feature only and won't work with other DBs. It would be cool if it does though. - Eric McVicker
Actually it is not "MS Style". The problem is getting the notification out, and this is impossible to do with SQL. This is simply not something ever put into the standard. MS uses a YUKON specific (yes, yukon - 2000 will not allow rpw level notifications) extension.
And yes, it rocks for O/R mappers. Sort of. It is not the holy grail - it is nice, but every O/R mapper relying on it exclusively is stupid. The market is bigger. But it is COOL. Why did you now know about it earlier?
Ups, sorry, should have read "why did you NOT know about it earlier". I remember seeing it months ago in a feature list somewhere. It is actually a VERY nice feature. Once I have some time I will get it working with the EntityBroker. It is definitly the missing
link - the event fom the database :-) And, btw., the mechanism actually really works.
If it's done by SQL, kindof the current SQL server notification service, which is not very attractive. But if MS can pave the infrastructure in a cool way, probably Oracle, or other DB vendors can create the Notification Provider. It's nothing wrong to depend
on it, in my opinion. I can see the provider could be out for other DB vendors sooner or later (Somebody from MS already implementated a WMI based cache invalidator.) Actually we just need a "OK" from MS, and they provide the implementation for SQL server,
and everybody else work on other DB vendors. And the worst case is disable the Cache for other DB vendors, which is not bad either. For God's sake, that what every O/R mapper's doing, default to no Cache, right? This can be a very nice Add on.
cklein
Participant
1561 Points
363 Posts
A Bomb in O/R mapper Caching strategy
Oct 21, 2003 05:15 PM|LINK
http://www.raincoder.com
Equal parts art and science
Email: cguo@raincoder.com
JOAC
Participant
1880 Points
376 Posts
Re: A Bomb in O/R mapper Caching strategy
Oct 21, 2003 05:47 PM|LINK
cklein
Participant
1561 Points
363 Posts
Re: A Bomb in O/R mapper Caching strategy
Oct 21, 2003 05:54 PM|LINK
http://www.raincoder.com
Equal parts art and science
Email: cguo@raincoder.com
thona
Member
20 Points
2923 Posts
Re: A Bomb in O/R mapper Caching strategy
Oct 21, 2003 05:59 PM|LINK
JOAC
Participant
1880 Points
376 Posts
Re: A Bomb in O/R mapper Caching strategy
Oct 21, 2003 06:27 PM|LINK
thona
Member
20 Points
2923 Posts
Re: A Bomb in O/R mapper Caching strategy
Oct 21, 2003 07:30 PM|LINK
cklein
Participant
1561 Points
363 Posts
Re: A Bomb in O/R mapper Caching strategy
Oct 21, 2003 07:31 PM|LINK
http://www.raincoder.com
Equal parts art and science
Email: cguo@raincoder.com