Remove ofy support from HistoryEntry (#1823)

This PR removes all Ofy related cruft around `HistoryEntry` and its three subclasses in order to support dual-write to datastore and SQL. The class structure was refactored to take advantage of inheritance to reduce code duplication and improve clarity.

Note that for the embedded EPP resources, either their columns are all empty (for pre-3.0 entities imported into SQL), including their unique foreign key (domain name, host name, contact id) and the update timestamp; or they are filled as expected (for entities that were written since dual writing was implemented).

Therefore the check for foreign key column nullness in the various `@PostLoad` methods in the original code is an no-op as the EPP resource would have been loaded as null. In another word, there is no case where the update timestamp is null but other columns are not.

See the following query for the most recent entries in each table where the foreign key column or the update timestamp are null -- they are the same.

```
[I]postgres=> select MAX(history_modification_time) from "DomainHistory" where update_timestamp is null;
            max
----------------------------
 2021-09-27 15:56:52.502+00
(1 row)

[I]postgres=> select MAX(history_modification_time) from "DomainHistory" where domain_name is null;
            max
----------------------------
 2021-09-27 15:56:52.502+00
(1 row)

[I]postgres=> select MAX(history_modification_time) from "ContactHistory" where update_timestamp is null;
            max
----------------------------
 2021-09-27 15:56:04.311+00
(1 row)

[I]postgres=> select MAX(history_modification_time) from "ContactHistory" where contact_id is null;
            max
----------------------------
 2021-09-27 15:56:04.311+00
(1 row)

[I]postgres=> select MAX(history_modification_time) from "HostHistory" where update_timestamp is null;
            max
----------------------------
 2021-09-27 15:52:16.517+00
(1 row)

[I]postgres=> select MAX(history_modification_time) from "HostHistory" where host_name is null;
            max
----------------------------
 2021-09-27 15:52:16.517+00
(1 row)
```
This commit is contained in:
Lai Jiang 2022-11-01 21:17:20 -04:00 committed by GitHub
parent 5df9a2e4aa
commit ad4aa73328
88 changed files with 845 additions and 2213 deletions

View file

@ -463,7 +463,7 @@ automatic one-year renewal at the instant a domain would expire).
ICANN prohibits any registration from being longer than ten years so if the
request would result in a registration greater than ten years long it will fail.
In practice this means it's impossible to request a ten year renewal, since that
In practice this means it's impossible to request a ten-year renewal, since that
will always cause the new registration to be longer than 10 years unless it
comes in at the exact millisecond that the domain would have expired.
@ -523,14 +523,14 @@ cannot be restored. After that period anyone can re-register this name.
This flow is called a restore "request" because technically it is only supposed
to signal that the registrar requests the restore, which the registry can choose
to process or not based on a restore report that is submitted through an out of
band process and details the request. However, in practice this flow does the
restore immediately. This is allowable because all of the fields on a restore
to process or not based on a restore report that is submitted through an
out-of-band process and details the request. However, in practice this flow does
the restore immediately. This is allowable because all the fields on a restore
report are optional or have default values, and so by policy when the request
comes in we consider it to have been accompanied by a default-initialized report
which we auto-approve.
Restores cost a fixed restore fee plus a one year renewal fee for the domain.
Restores cost a fixed restore fee plus a one-year renewal fee for the domain.
The domain is restored to a single year expiration starting at the restore time,
regardless of what the original expiration time was.