Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
More aggressive entity caching (Trac #4543) #4543
Original ticket http://trac.elgg.org/ticket/4543 on 42396522-09-29 by ewinslow, assigned to ewinslow.
Elgg version: 1.7
The above situation is common and pointless. We already loaded the entity, we should just be able to hit a local cache (i.e. it should not require a shared memory cache like memcache).
Once we have this optimization in place for
Since this is invisible to the API, we can include it in a bugfix release, so I'm slating for 1.8.x.
trac user mrclay wrote on 42404337-05-18
Yes! I had an idea like the but was worried about the possibilities of having multiple instances of the same entity pointing to different objects. E.g. Using the constructor will always produce a distinct object. The answer to this is, that's already possible. It might be worth considering having all entity construction done via a public static method (making constructor private), which would mean the cache can always be checked and identical GUIDs always point to the same object (unless low on memory). I wonder if the patch could be a bit more clever instead of a static limit on the cache size. Even as is, this is awesome.