[QUESTION] Is it possible that dynamoose causes an SQLite syntax error on DynamoDB local?

Summary:

Context:

• Problem found while upgrading from Nodejs 6 to 12 and with that the project’s dependencies.
• Upgraded from dynamoose v0.8.7 to v2.3.0
• Containerized application using docker-compose: backend and dynamodb instance only Docker file for dynamodb:

FROM openjdk:latest

# Bundle dynamodb
COPY . .

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

Problem: when lifting up the containers, after the backend initializes the dynamodb instance throws the errors below, causing any subsequent query or call to stall and return on timeout on the backend’s side.

Error:

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)

I suspect this is happening when creating the tables through Dynamoose’s model().

I’m currently just analysing the upgrade to nodejs 12 and dynamoose 2.3. In local I would prefer to have it run to test other parts of the project, so I don’t mind updating indexes and recreating tables, but wish to know where this syntax error is coming from to fix it and carry on.

Question: Is it possible that dynamoose causes a DynamoDB local instance to attempt to drop an index with an SQLite syntax error?

Environment:

Operating System: Debian stretch running on top of WSL2 in Docker for windows Operating System Version: 9 Node.js version (node -v): 12.18.3 NPM version: (npm -v): 6.14.6 Dynamoose version: 2.3.0

Other:

• I have read through the Dynamoose documentation before posting this issue
• I have searched through the GitHub issues (including closed issues) and pull requests to ensure this question has not already been raised before
• I have searched the internet and Stack Overflow to ensure this question hasn’t been raised or answered before
• I have filled out all fields above
• I am running the latest version of Dynamoose

[edg956]

@fishcharlie sure, go ahead. Thank you!

[edg956]

Hi @fishcharlie. I don’t really know why whoever programmed it did it like that and honestly I did not look into it anymore. Didn’t want to close this before I could get back to it, sorry!