Hi Oleg > > Or maybe it would make sense to use a Collection inside the in-memory > > adapter to store the records and have this functionality pushed to > > Collection? > > I think, InMemoryAdapter should be somehow chained with a regular > adapter and replace current IdentityMap implementation.
While this could be functional, it wouldn't perform anywhere nearly as well as the current IdentityMap implementation, which is based on a Hash. It's important that the IM be as fast as possible, since it's sole purpose is to allow lookups of previously instantiated resources. When you load resources inside a repository block it creates one entry in the IM. So if you load 10,000 resources, that'd be 10,000 entries. It would likely be alot slower to use Enumerable#detect to find the resource than to look it up in a Hash by it's key. > That is, InMemoryAdapter would act like a cache in front of regular > repository. > Also, you can port my sorting code into the InMemoryAdapter. Thanks. The latest InMemoryAdapter (in my fork at github.com/dkubb/dm- core) has sorting, limiting and conditions matching but I will check it against your implementation to see if there's anything missing. Dan (dkubb) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
