Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request? Query by > 1 partition key values. #387

Closed
patrickquigley102 opened this issue May 23, 2024 · 2 comments
Closed

Feature Request? Query by > 1 partition key values. #387

patrickquigley102 opened this issue May 23, 2024 · 2 comments

Comments

@patrickquigley102
Copy link

patrickquigley102 commented May 23, 2024

Hey 👋

My little tech company has adapted this library for our in-house serverless framework, so we've currently ~15 engineers learning this library. And it's in use in Production. We like it, thank you for making it.

I've read all previous issues, all the docs and I'm not sure if my request is currently a supported feature. I also read the discussions.

I'm new to the library and DynamoDB, so may have missed the obvious.

I would like to be able to use ElectroDB to query DynamoDB with multiple partition query values. Here is a playground illustrating what I mean.

Also in brief it'd look something like this.

Entity.query(partition_keys: ['uid1', 'uid2'])

I know this is a supported feature of DynamoDB, as I've working examples in both NoSQLWorkbench and in the AWS Console. Which I can share validation of if needed but will omit for now, beyond the PartiQL statement.

select * from "table" where "partition_key" in ['uid1', 'uid2']

Thanks for your time.

P.S. Treat yourself to a breakfast pastry, you deserve it.

@tywalch
Copy link
Owner

tywalch commented May 23, 2024

Hey @patrickquigley102 👋

Great question, and I am glad you have found the library so helpful!

The short of the long is that it is not currently a feature because it is not an available operation via the DymamoDB DocumentClient. Ultimately it could be a feature, though behind the scenes it would ultimately be syntactic sugar for multiple requests. I suspect that is also what the SQL you shared is also doing when it's exectuted.

That said, not to leave you empty handed, here is how I would begin to implement something like that. The difficultly with abstracting away multiple calls is that you have to start making hard decisions around pagination, handling partial failures, ordering, and more. That's is usually why I try to keep ElectroDB out of the business of making decisions for the user on when to make more than one request; what is helpful for one use-case can be a total arm-bar to another use-case.

Let me know if this helps!

@patrickquigley102
Copy link
Author

Hey.

Thanks for the information 🙂. That's helpful.

start making hard decisions around pagination, handling partial failures, ordering, and more.

Aye, this is what I fear. And was hoping you'd already done it 😂.

And it makes sense to keep it out of ElectroDB,.

I'll likely redesign the single table to meet the access patterns within ElectroDB's features. or change the requirements to fit the current limitation I've built.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants