【问题标题】:Is it possible that aws-sdk/dynamoose causes an SQLite syntax error on DynamoDB local?aws-sdk/dynamoose 是否可能在本地 DynamoDB 上导致 SQLite 语法错误?
【发布时间】:2020-12-22 11:59:11
【问题描述】:

上下文

从 Nodejs 6 升级到 12 以及项目的依赖项时发现问题。 使用 dynamoose 2.3 使用 docker-compose 的容器化应用程序:仅后端和 dynamodb 实例

dynamodb 的 Docker 文件:

FROM openjdk:latest

\# Bundle dynamodb
COPY . .

EXPOSE 8000
CMD [ "java", "-jar", "DynamoDBLocal.jar" ]

问题:提起容器时,后端初始化dynamodb实例后抛出以下错误,导致任何后续查询或调用停止并在后端超时返回。

错误

dynamodb_1  | Sep 03, 2020 8:14:36 AM com.almworks.sqlite4java.Internal log
dynamodb_1  | WARNING: [sqlite] SQLiteDBAccess$10@b6f156c: job exception
dynamodb_1  | com.almworks.sqlite4java.SQLiteException: [1] DB[1] prepare() DROP INDEX Foobar*HVI; [near "*": syntax error]
dynamodb_1  |   at com.almworks.sqlite4java.SQLiteConnection.throwResult(SQLiteConnection.java:1436)
dynamodb_1  |   at com.almworks.sqlite4java.SQLiteConnection.prepare(SQLiteConnection.java:580)
dynamodb_1  |   at com.almworks.sqlite4java.SQLiteConnection.prepare(SQLiteConnection.java:635)
dynamodb_1  |   at com.almworks.sqlite4java.SQLiteConnection.prepare(SQLiteConnection.java:622)
dynamodb_1  |   at com.amazonaws.services.dynamodbv2.local.shared.access.sqlite.AmazonDynamoDBOfflineSQLiteJob.getPreparedStatement(AmazonDynamoDBOfflineSQLiteJob.java:138)
dynamodb_1  |   at com.amazonaws.services.dynamodbv2.local.shared.access.sqlite.SQLiteDBAccess$10.dropGSISQLiteIndex(SQLiteDBAccess.java:1221)
dynamodb_1  |   at com.amazonaws.services.dynamodbv2.local.shared.access.sqlite.SQLiteDBAccess$10.dropIndices(SQLiteDBAccess.java:1169)
dynamodb_1  |   at com.amazonaws.services.dynamodbv2.local.shared.access.sqlite.SQLiteDBAccess$10.doWork(SQLiteDBAccess.java:1155)
dynamodb_1  |   at com.amazonaws.services.dynamodbv2.local.shared.access.sqlite.SQLiteDBAccess$10.doWork(SQLiteDBAccess.java:1152)
dynamodb_1  |   at com.amazonaws.services.dynamodbv2.local.shared.access.sqlite.AmazonDynamoDBOfflineSQLiteJob.job(AmazonDynamoDBOfflineSQLiteJob.java:97)
dynamodb_1  |   at com.almworks.sqlite4java.SQLiteJob.execute(SQLiteJob.java:372)
dynamodb_1  |   at com.almworks.sqlite4java.SQLiteQueue.executeJob(SQLiteQueue.java:534)
dynamodb_1  |   at com.almworks.sqlite4java.SQLiteQueue.queueFunction(SQLiteQueue.java:667)
dynamodb_1  |   at com.almworks.sqlite4java.SQLiteQueue.runQueue(SQLiteQueue.java:623)
dynamodb_1  |   at com.almworks.sqlite4java.SQLiteQueue.access$000(SQLiteQueue.java:77)
dynamodb_1  |   at com.almworks.sqlite4java.SQLiteQueue$1.run(SQLiteQueue.java:205)
dynamodb_1  |   at java.base/java.lang.Thread.run(Thread.java:832)

我怀疑在通过 Dynamoose 的 model() 创建表时会发生这种情况,该模型在后台调用 aws 的 DynamoDB createTable 方法。

我目前正在分析升级到 nodejs 12 和 dynamoose 2.3。在本地,我更愿意让它运行以测试项目的其他部分,所以我不介意更新索引和重新创建表,但想知道这个语法错误来自哪里来修复它并继续。

问题:是否有可能是 aws-sdk 或 dynamoose 导致 DynamoDB 本地实例尝试删除带有 SQLite 语法错误的索引?

【问题讨论】:

    标签: amazon-dynamodb aws-sdk-js dynamoose amazon-dynamodb-local


    【解决方案1】:

    删除我的“docker/dynamodb”文件夹中的“shared-local-instance.db”文件为我解决了这个问题(该文件在 docker-compose up 上再次生成,一切正常)

    【讨论】:

      【解决方案2】:

      问题在于 Dynamoose 0.8.7 曾经支持具有哈希键属性和标记为全局索引的模式。跳转到最新版本时,一些重大更改使其在查询中添加了 '*' 之类的字符,从而使 SQLite 抱怨。

      例子:

      const FoobarSchema = new dynamoose.Schema({
          foo: {
              type: String,
              hashkey: true,
              index: {
                   global:true
              }
          }
      });
      
      const Foobar = dynamoose.model('Foobar', FoobarSchema, Options); // Blow up
      

      我是该项目和 DynamoDb 的新手。我不明白将这两个条件放在一起的原因是什么,以及是否应该支持它。有机会我会更深入地研究它并更新它。

      【讨论】:

        猜你喜欢
        • 2018-06-21
        • 1970-01-01
        • 2012-06-02
        • 2022-08-02
        • 2021-10-15
        • 2015-10-02
        • 1970-01-01
        • 1970-01-01
        • 2022-01-02
        相关资源
        最近更新 更多