zydronium/google-nomulus
1
0
Fork 0
mirror of https://github.com/google/nomulus.git synced 2025-05-21 11:49:37 +02:00
Code Issues Projects Releases Packages Wiki Activity

Remove datastore related code (#1906)

Browse source
This commit is contained in:
Lai Jiang 2023-01-19 14:44:11 -05:00 • committed by GitHub
parent 913edb23ee
commit e41fd7877e
152 changed files with 886 additions and 4460 deletions
Download patch file Download diff file Expand all files Collapse all files

73
docs/coding-faq.md
View file

@ -3,50 +3,6 @@
This file is a motley assortment of informational emails generated in response
to questions from development partners.
## Which entities are backed up using commit logs?
Short answer: Check the file `backup_kinds.txt`.
Long answer: There are really two axes. Our custom Ofy actually doesn't
condition commit logging on the `@Entity` class being mutated. Rather, it
conditions based on:
1. the methods you're invoking
1. annotations on the class being mutated
**Methods:** The standard `save()` and `delete()` methods always write commit
logs. The alternate `saveWithoutBackup()` and `deleteWithoutBackup()` methods
never write commit logs (and have appropriately scary names to avoid accidental
use). This makes it clear what you're getting at the callsite.
**Annotations:** There are regular `@Entity`-annotated entities,
`@VirtualEntity`-annotated entities, and `@NotBackedUp`-annotated entities. An
`@VirtualEntity` is a "virtual entity" that just serves to construct parent keys
for other entities (e.g. `EppResourceIndexBucket`) and is never written to
Datastore itself. An `@NotBackedUp`-annotated entity is one that specifically
shouldn't be backed up (like the commit log entities themselves).
We don't actually prevent you from not-backing-up a regular entity, because
sometimes that's necessary (e.g. in the restore logic, and some other
miscellaneous places). We do prevent you from trying to save/delete an
`@VirtualEntity` (with or without backups) or save/delete an `@NotBackedUp`
entity with backups (i.e. using the regular `save()`/`delete()` calls), since
these are always usage errors.
We went with an `@NotBackedUp` annotation versus an `@BackedUp` annotation
largely because the not-backed-up case is more of the special case (as explained
above, the annotation itself doesn't directly turn backups on or off). To keep
track of what we're intending to back up, we:
1. synthesize a list of all the backed-up kinds by filtering the registered
entity classes to remove those with `@VirtualEntity` and `@NotBackedUp`
annotations:
[`ExportConstants`](https://github.com/google/nomulus/blob/master/java/google/registry/export/ExportConstants.java#L82),
1. check this list into the repo:
[`backup_kinds.txt`](https://github.com/google/nomulus/blob/master/javatests/google/registry/export/backup_kinds.txt), then
1. run an enforcement test to make sure it is up to date:
[`ExportConstantsTest`](https://github.com/google/nomulus/blob/master/javatests/google/registry/export/ExportConstantsTest.java#L55).
## How do I mock Google Cloud Storage in tests?
AppEngine's GCS client automatically switches over to a local implementation,
@ -142,31 +98,4 @@ specify .domain.tld after the nameserver wildcard (e.g. ns*.domain.tld). But you
can't do anything else, like searching for nameservers with ns*.tld. When using
a wildcard, we currently require a prefix of at least two characters, to avoid
having someone search for *. There are other limitations to the system which we
plan to address in the future.
## How do I embed a new class in an existing Datastore entity class?
In Objectify 4.x, which we are pinned to, you have to annotate a class with
@Embed in order to natively nest it within an entity, e.g. as a field within an
@Entity class. This behavior is different from how things work in Objectify 5.x,
which is what the current documentation reflects. Unfortunately the 4.x docs are
hard to access, but you can search this old copy for "embed" to see the details:
[https://raw.githubusercontent.com/objectify/objectify-legacy-wiki/v4/Entities.wiki](https://raw.githubusercontent.com/objectify/objectify-legacy-wiki/v4/Entities.wiki)
So you'd have to annotate your subobject with @Embed for it to work. It's
possible in Objectify 4.x to have a class that's both @Embed and @Entity, but
it'd be a little unorthodox. Usually it'd be cleaner to either make it purely
@Embed (so purely a container for data within the parent entity) or purely
@Entity, in which case you wouldn't use it as a field of the other @Entity but
would instead refer to it by key, e.g. you'd store a Key<MySubObject> instead.
For objects which don't change very often, it is preferable to use the @Entity
approach.
## How do I resolve Bazel package visibility problems?
As a short-term solution, you can disable the bazel visibility checking with
[`--nocheck_visibility`](https://www.bazel.io/versions/master/docs/bazel-user-manual.html#flag--check_visibility).
We are investigating ways to clarify the way that custom functionality is
expected to be added, which will involve changing the package visibility
accordingly.
plan to address in the future.