Use transaction time when cloneProjectedAtTime()-ing within transaction

It's bad practice in terms of data model consistency to use DateTime.now(UTC) for cloneProjectedAtTime() within a transactional context - instead, we should always use ofy().getTransactionTime() when it's available.  The ofy transaction time is frozen at the start of the transaction attempt, whereas DateTime.now(UTC) will continue marching ahead.  So using it for a cloneProjectedAtTime() could mean materializing the outcome of logical-time-dependent events (like autorenews, or transfers, or grace period expirations) at a logical time (i.e. commit log time) prior to when they should actually have occurred.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170501277
This commit is contained in:
nickfelt 2017-09-29 10:41:36 -07:00 committed by Ben McIlwain
parent dc41d7923e
commit bc02b701b5

View file

@ -16,7 +16,6 @@ package google.registry.batch;
import static google.registry.model.ofy.ObjectifyService.ofy;
import static google.registry.util.PipelineUtils.createJobPath;
import static org.joda.time.DateTimeZone.UTC;
import com.google.appengine.tools.mapreduce.Mapper;
import com.google.common.collect.ImmutableList;
@ -29,7 +28,6 @@ import google.registry.request.Action;
import google.registry.request.Response;
import google.registry.request.auth.Auth;
import javax.inject.Inject;
import org.joda.time.DateTime;
/**
* A mapreduce that re-saves all EppResources, projecting them forward to the current time.
@ -76,7 +74,7 @@ public class ResaveAllEppResourcesAction implements Runnable {
@Override
public void vrun() {
EppResource projectedResource =
ofy().load().key(resourceKey).now().cloneProjectedAtTime(DateTime.now(UTC));
ofy().load().key(resourceKey).now().cloneProjectedAtTime(ofy().getTransactionTime());
ofy().save().entity(projectedResource).now();
}});
getContext().incrementCounter(String.format("%s entities re-saved", resourceKey.getKind()));