Use ordered sets to make sure that we don't pick up the same domain more than once if we find more than one of its nameservers, while preserving the order in which the domains are found. Add tests to make sure it works.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134821458
Eclipse (with Guide) is bothering me very much that it cannot infer the intended
type for ImmutableList.of() from the argument type that the calling function
defines. Adding explicit type parameters to get rid of the annoying exclamations
marks in Eclipse.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=134105086
It is replaced by loadByForeignKey(), which does the same thing that
loadByUniqueId() did for contacts, hosts, and domains, and also
loadDomainApplication(), which loads domain application by ROID. This eliminates
the ugly mode-switching of attemping to load by other foreign key or ROID.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133980156
It appears to be standard RDAP practice when returning result sets for domain, nameserver and entity searches to give only summary data for each result item. Any information that can be gleaned from the object itself is included, but related resources are not included. For a domain, for instance, the domain information is included, but nameservers, entities and events (which come from history entries) are suppressed. In their place, there is a standard boilerplate remark in the object indicating that only summary data is included, and that the user should query the item directly to get the full data. Note that summary data is used only for searches; direct queries for an item will still return full data.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133973835
Because we cannot weed out deleted domains in the query itself, the RDAP code must pull all domains with matching names, then throw out the deleted domains. So we don't know how many domains to fetch up front to fill up the desired maximum result set size. This CL adds a loop to attempt to fetch addition domains if the first fetch did not yield enough, while giving up after a while to avoid bogging down the system.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=133420297
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
The ICANN operational profile says:
1.4.12. An entity object within an RDAP response MUST contain an events
member with the following events:
o An event of eventAction type registration.
o An event of eventAction type last changed. The event of eventAction type last changed MUST be omitted if the Contact Object (as defined in RFC5733) has not been updated since it was created.
o An event of eventAction type last update of RDAP database.
It has similar wording for domains and hosts. The registration and last changed events are already being generated. This CL adds a "last update of RDAP database" event for all three object types. It's very redundant, and I have warned ICANN that "last update" doesn't mean what they might expect in the context of an eventually consistent database, but there we are.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=130279688
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.
2016-05-13 18:55:08 -04:00
Renamed from java/com/google/domain/registry/rdap/RdapDomainSearchAction.java (Browse further)
