'bucket' doesn't sound right, as that seems to imply a service which is static storage (coming from the AWS world).
I would think "table" - but then I'm not familiar with CosmosDB (is it the same as MongoDB?), and in ElasticSearch we're talking "index".
Additionally, in ElasticSearch you're looking at all-lower-case names for your indexes, whereas they are capitalised table names for DynamoDB and CosmosDB - just looking at your code, and taking consistency into consideration.

I went for 'dynamodb' under 'search' because it seemed to match your 's3.bucket' under 'storage'. Didn't occur to me to rewrite the whole of the backend ...

On that note, the configuration has a tree of "storage.s3.bucket" with a folder hierarchy of "storage.aws.S3StorageRepository", while "search.[backend | elasticsearch | azure]" has a matching folder hierarchy of "backend.[aws.dynamodb | azure.cosmosdb | elasticsearch]".
I would think you could change either one. Not being intimately familiar with this application admittedly, but I'd think you could replace "search" with "backend" in the config, and "backend" with "type" or "service". That would feel a little more consistent between the config and the code structures.

I won't touch that config or code folder structure, but I'll just put in your "bucket.names" and see if I can reflect it in the rest of the code, then submit that as a pull request.

It looks like all-lowercase is the convention for ElasticSearch indexes;
https://www.elastic.co/guide/en/ecs/current/ecs-conventions.html
So I'll just use a "lower" function or something. Guess that means I'll have to reinstall some sort of Java parser in my IDE to check my work 😅 Haven't touched Java in quite a while.

Uh oh!

Configurable dynamodb table names #476

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions