房间中的物件大小限制

时间:2018-09-30 15:17:42

标签: android database object null size

这是有关Room Persistence库如何在Android中运行的一般问题。 我遇到了Room的一个可能的错误/功能,如果我试图将其中包含太多数据的POJO插入到Room Object DAO中,然后稍后通过id或特定字段查询该对象,则结果为空。

在这种情况下,Room绝对不提供任何故障/错误日志,我花了一段时间才发现,如果我将大对象分割成两个包含一半数据的对象,那么以后我就可以查询两个对象(我注意到在Db中正确查询了另一个3500个String子对象的POJO,但是上面提到的超大对象有6500个String子对象。

具体来说,以下是有问题的对象的结构,为简单起见,我在其中排除了吸气剂/吸气剂:

@Entity(tableName = KanjiComponent.TABLE_NAME)
public class KanjiComponent {

    public KanjiComponent() {}

    @PrimaryKey(autoGenerate = true)
    @ColumnInfo(index = true, name = COLUMN_ID)
    public long id;

    @ColumnInfo(name = COLUMN_COMPONENT_STRUCTURE)
    private String structure;

    @TypeConverters({MyAppDbTypeConverters.class})
    private List<KanjiComponent.AssociatedComponent> associatedComponents;

    public static class AssociatedComponent {
        private String component;
        private String associatedComponents;
    }
}

KanjiComponent.AssociatedComponent中的“组件”字段是一个单字符字符串,但KanjiComponent.AssociatedComponent中的“ associatedComponents”字段可以是从短字符串到超长字符串“;”的任何内容。分隔字符。

KanjiComponent.AssociatedComponent的列表在我有问题的对象中的大小为6500,而List大小最大为3500的对象没有遇到任何问题。 因此,我用KanjiComponent.AssociatedComponent创建了两个对象,列表大小分别为3000和3500,现在一切正常。

我所有的插入/请求都是在后台线程上完成的,并且请求完整的数据库(List<KanjiComponent> list = myDatabase.getInstance().getAllKanjiComponents())也会产生大小为0的结果,即使现在有19个有效的KanjiComponent对象(即最多3500个子对象)每个)。

在同一应用程序和同一后台线程中请求其他对象数据库可以正常工作。查询上述完整数据库的大小为0,但是可以完全请求另一个包含85000个小型对象的POJO数据库,列表大小为85000。因此Room本身没有问题。

我猜想Android或Room中的POJO都有固有的对象大小限制,但是我无法找到有关此信息。我也不确定如何测量大型POJO的大小以找到该问题大小阈值的值。

有人遇到这个问题吗? 除了将超大对象插入到房间之前手动分割它们之外,还有其他解决方法吗? Room / Android中的对象大小和/或子对象计数限制是什么?

谢谢

1 个答案:

答案 0 :(得分:1)

  

我猜想Android或Room中的POJO都有固有的对象大小限制,但是我无法找到有关此的信息

任何结果集超过1MB的查询都容易出现问题。尽管从原理上讲它应该起作用,但实际上我的目标是避免它。

  

我有问题的对象中的KanjiComponent.AssociatedComponent列表大小为6500

所以,要清楚:

  • 您有一个超过6,500个对象的列表
  • 这些对象中的每个对象都可以具有一个字符串,该字符串为“非常长的字符串,为“;”分隔字符“
  • 您正在使用TypeConverters将所有内容都塞入单个列中

如果是这样,由于OutOfMemoryErrors,我希望这是非常不可靠的。

  

除了在将超大对象插入到Room中之前手动对其进行分割之外,还有更好的解决方法吗?

更改数据库设计,以避免出现大量列。有两个带有相应“房间”实体的表。 AssociatedComponent拥有自己的表/实体,在KanjiComponentAssociatedComponent之间具有1:N的关系。考虑使用分页库仅根据需要将子集加载到内存中(例如,用于滚动列表)。