It's best to be consistent and use the same thing everywhere. "clientId" was
already used in more places and is shorter and no more ambiguous, so it's the
logical one to win out.
Note that this CL is almost solely a big Eclipse-assisted refactoring. There are
two places that I did not change clientIdentifier -- the actual entity field on
Registrar (though I did change all getters and setters), and the name of a
column on the exported registrar spreadsheet. Both would require data
migrations.
Also fixes a few minor nits discovered in touched files, including an incorrect
test in OfyFilterTest.java and some superfluous uses of String.format() when
calling checkArgument().
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133956465
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
This will help [] be submitted without breaking the linter.
License headers are now added automatically where they were previously
added by hand. We're also now adding the license header to Soy and SQL
files.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=129017424
This is an internal-only feature that breaks the open source build.
CL created with:
dr-replace '(compatible_with.*)' '\1 # MOE:strip_line'
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=128852873
The presubmits are warning that toUpperCase() and toLowerCase() are locale-specific, and advise using Ascii.toUpperCase() and Ascii.toLowerCase() as a local-invariant alternative.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=127583677
XjcToContactResourceConverter is, as it name suggests, an inverse of
ContactResourceToXjcConverter. This utility class is designed to
support the TLD data import feature.
EXTERNAL_REVIEW_URL=https://github.com/google/domain-registry/pull/19
GIT_AUTHOR=Wolfgang Meyers <wolfgang@donuts.co>
(With some minor changes by Ben McIlwain.)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=125985714
RdeParser can parse an escrow deposit file from a stream without
loading the entire file into memory, but offers the convenience
of parsing RDE elements into their jaxb object representation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=124142087
The methods in DomainBase were the only callers for the methods in
EppResourceUtils, so I first inlined them. Then I realized that there
were no callers for loadReferencedContacts() anywhere. For loadNameservers(),
all but one invocation actually wanted to load the foreign keys, and was
repeating that work, so I replaced it with loadNameserverFullyQualifiedHostNames().
The last invocation, in the Rdap code, was incorrectly assuming this was an async
load when in fact it blocks, so I replaced it with a real async load.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=122433897
ReferenceUnion is a hack to work around the mismatch between how
we store references (by roid) and how they are represented in EPP
(by foreign key). If it ever needed to exist (not entirely clear...)
it should have remained tightly scoped within the domain commands
and resources. Instead it has leaked everywhere in the project,
causing lots of boilerplate. This CL hides all of that behind
standard Refs, and should be followed by work to remove ReferenceUnion
completely.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=122424416
It's no longer used by the current RDE system. Also, remove an unused
Dagger @PRovides method for the rde-upload queue.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=122164826
Java's stock regex implementation doesn't guarantee linear time
complexity which makes it a security liability.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=121159875
The dark lord Gosling designed the Java package naming system so that
ownership flows from the DNS system. Since we own the domain name
registry.google, it seems only appropriate that we should use
google.registry as our package name.
This change renames directories in preparation for the great package
rename. The repository is now in a broken state because the code
itself hasn't been updated. However this should ensure that git
correctly preserves history for each file.
