static void _RunCacheDemo()
{
// Normally, you don't really have to mess with the cache in a desktop app
// or a console app. Long running apps and services will require some
// maintenance. Otherwise caching is automatic.
// Fetch a show.
var show = new TmdbShow(2919); // get "Burn Notice"
var movie = new TmdbMovie(219); // fetch "Volver"
// right now our entries only have an id. use some properties
// so we can get the show into the cache.
Console.WriteLine("Fetched {0} from tmdb", show.Name);
Console.WriteLine("Fetched {0} from tmdb", movie.Name);
// write the cache to a file in the project directory
//Tmdb.SaveCacheTo(@"..\..\cache.json");
// we won't use the above helper method since we want our cache to
// be pretty printed
JsonObject.SaveTo(Tmdb.Json, @"..\..\cache.json", " ");
// Note that the cache is thread static. It's per thread instance.
// Do not pass objects between threads. Serialize if you must like above
// or in memory.
// clear our cache.
Tmdb.Json.Clear();
// any existing instances will be orphaned. this impacts equality as well.
// if you MUST re-cache an orphaned object, what you can do is this:
movie = new TmdbMovie(movie.Json);
// this will copy the old json data into a new movie instance which will then root
// that in the current cache.
// should only have the movie we just re-rooted above in it.
Console.WriteLine(Tmdb.Json);
// that's cool but how about we load our cache that we saved?
Tmdb.LoadCacheFrom(@"..\..\cache.json");
// Note that this MERGES the loaded data with the existing data.
// You can call it multiple times in a row with different files
// if you ever wanted to. This might be useful down the road
// for cache differentials in a distributed system. There's also
// LoadCacheFromUrl() with an eye toward distribution down the
// road
// remember if we create new TmdbEntry instances like movie or
// TV objects, they will use the existing cache rather than
// fetching from TMDB.
// So, since we loaded the cache we should now be able to do
show = new TmdbShow(3050);
Console.WriteLine("This is cached: {0}", show.Name);
// without making any remote requests.
// use value equality semantics.
// get the show again, this time through a search.
// searches themselves are not cached, but each individual result
// is. That means The Practice will get filled in with any additional
// data returned from the search query.
var showComparand = Tmdb.SearchShows("The Practice", minPage: 0, maxPage: 0)[0];
// check to make sure showComparand and show are actually two different TmdbShow wrapper instances
// should report that they are different
Console.WriteLine("Instances are {0} actual objects", ReferenceEquals(show, showComparand) ? "the same" : "different");
// check to make sure showComparand and show are actually logically equal.
// should report that they are the equal
Console.WriteLine("Instances are logically {0}", show == showComparand ? "equal" : "not equal");
// NOTES:
// Clearing the cache "unroots" all existing instances of TmdbEntry
// derived classes. They will no longer operate on anything you have a
// root for. In fact, they are still writing to parts of the old cache.
// The moral is don't hang on to object instances for longer than you need
// them. Don't store them as class members or in collections just because.
// Instead, use them and throw them away. Get a new object when you need
// it. This will ensure that the most current cache is the one being used.
// our show and movie instances are still valid, but are not writing or
// reading from the current cache.
// This also impacts equality. Objects from the old cache cannot be compared
// to objects from the new cache. They will always return false.
// Because of the above, it's best to release all instances of the old objects
// when you clear the cache. The system does not track which object instances
// are expired objects. You can check if an object is expired manually, but it's
// expensive.
// ideally, a batch of operations is performed, then the cache can be cleared, then
// the next batch (with all new objects) is performed, if you clear the cache at all.
// a server app or a long running desktop app should clear it periodically, but doing
// so will make a bunch of HTTP requests happen again, even if they already happened
// since they weren't cached anymore.
// The HTTP requests might be cached through the second level caching mechanism.
//
// if you like, you can save and load the cache from disk, that way you can keep the cache
// across application runs. Eventually it will get big and stale though. In the future I
// might monitor the Tmdb.Configuration.ChangeKeys to expire old objects, if i can figure
// out how it works exactly.
}