cgoldfeder 5098b03af4 DeReference the codebase ... This change replaces all Ref objects in the code with Key objects. These are stored in datastore as the same object (raw datastore keys), so this is not a model change. Our best practices doc says to use Keys not Refs because: * The .get() method obscures what's actually going on - Much harder to visually audit the code for datastore loads - Hard to distinguish Ref<T> get()'s from Optional get()'s and Supplier get()'s * Implicit ofy().load() offers much less control - Antipattern for ultimate goal of making Ofy injectable - Can't control cache use or batch loading without making ofy() explicit anyway * Serialization behavior is surprising and could be quite dangerous/incorrect - Can lead to serialization errors. If it actually worked "as intended", it would lead to a Ref<> on a serialized object being replaced upon deserialization with a stale copy of the old value, which could potentially break all kinds of transactional expectations * Having both Ref<T> and Key<T> introduces extra boilerplate everywhere - E.g. helper methods all need to have Ref and Key overloads, or you need to call .key() to get the Key<T> for every Ref<T> you want to pass in - Creating a Ref<T> is more cumbersome, since it doesn't have all the create() overloads that Key<T> has, only create(Key<T>) and create(Entity) - no way to create directly from kind+ID/name, raw Key, websafe key string, etc. (Note that Refs are treated specially by Objectify's @Load method and Keys are not; we don't use that feature, but it is the one advantage Refs have over Keys.) The direct impetus for this change is that I am trying to audit our use of memcache, and the implicit .get() calls to datastore were making that very hard. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=131965491		2016-09-02 13:50:20 -04:00
..
HistoryEntry.java	DeReference the codebase	2016-09-02 13:50:20 -04:00