在 Android Studio 上使用 Android 和 Google App Engine

Question

我正在开发一个带有后端的应用程序，我决定尝试将 Google App Engine 用于我的后端。由于我是 Google App Engine 的新手，所以我对逻辑有点困惑。

基本上，我有几个模型类来表示我的对象类型。假设其中一个是用户，另一个是项目。用户拥有物品，并且一件物品可以属于多个用户。所以用户 X 可以有 25 个项目，包括项目 A，用户 Y 可以有完全不同的 20 个项目，还有项目 A。

现在我的 User 类看起来像这样：

@Entity
public class User {

    @Id private Long id;
    private String name;
    private String emailAddress;
    private String photoURL;

    //All getters and setters...
}

我的 Item 类大致相同。我的一个问题是，我应该在哪里添加某种列表，例如将项目列表添加到用户中。我应该使用哪个注释？该注释将为我提供什么结果（引用、ID 或完整对象）？

与此相关的另一个问题是，在我的端点类中，如何获取特定用户拥有的项目列表（或拥有特定项目的用户列表）？

最后一个完全不相关的问题，我应该做些什么来使 id 自动递增，或者如果我在插入项目时不提供任何 id 会自动递增吗？

Answer 1

您可以在数据存储中搜索两件事：键和索引属性。

class Thing {
   @Id Long id;
   @Index String property;
}

有时你会保存一些实体

Thing thing1 = new Thing();
thing1.property = "yes";
Thing thing2 = new Thing();
thing2.property = "no";
ofy().save().entities(thing1, thing2).now();

现在您可以根据索引属性搜索所有实体。例如。对于property == "yes" 的所有内容。

List<Thing> things = ofy().load().type(Thing.class).filter("property", "yes").list();

将准确返回 thing1。

这同样适用于属性列表。它适用于其他属性的引用/键列表。

class User {
    @Id Long id;
    @Index List<Key<Item>> items;
}

class Item {
    @Id
    Long id;
}

List<User> searchUsersWithItem(long itemId) {
    Key<Item> itemKey = Key.create(Item.class, itemId);
    return ofy().load().type(User.class).filter("items", itemKey).list();
}
List<User> searchUsersWithItem(Item item) {
    return ofy().load().type(User.class).filter("items", item).list();
}
// just loads all the referenced items in the owner
List<Item> searchItemsWithOwner(User owner) {
    return new ArrayList<Item>(ofy().load().<Item>values(owner.items).values());
}

filter 可用于引用、键和实体实例。

要找到的东西必须索引https://cloud.google.com/datastore/docs/concepts/indexes/https://github.com/objectify/objectify/wiki/Queries

你要决定的是如何为你的关系建模。有多种方法。一个用户拥有一组可以被一组用户拥有的项目实际上是一个多对多的关系。你可以像这样表示它

class User { List<Key<Item>> items; }
class Item { }

或

class User { }
class Item { List<Key<User>> owners; }

或

class User { List<Key<Item>> items; }
class Item { List<Key<User>> owners; }

甚至

class User { }
class Item { }
class Ownership { Key<Item> item; Key<User> user; }

每种方法在数据一致性和可搜索性/性能方面都有其起伏。在最初的示例中，搜索用户的所有项目是微不足道的，因为您所要做的就是加载该用户并且您拥有项目列表。另一个方向需要查询方式。

因此，就搜索性能而言，您可以从项目中的所有者列表以及用户中的项目列表中受益，因为这样您根本不需要查询。最大的缺点是数据一致性。如果您未能同时更新用户和项目，则您可能拥有认为由用户拥有的项目，而用户认为不同。

最后一种方法，使用显式的“所有权”实体本质上是传统的枢轴/连接表https://en.wikipedia.org/wiki/Many-to-many_%28data_model%29，这是将多对多关系转换为 2 个一对多关系的结果。使用它会导致容易的一致性，但查询性能最差。

父关系有时很有用，但前提是父关系需要存在实际的一对多关系。

还请注意，键与传统 SQL 数据库中的外键不同，因为它们可以在没有实体的情况下存在。因此，无论您做什么，都必须注意一致性。