Dynasaur: A DynamoDB ORM for Node.js(tglines.github.com)
tglines.github.com
Dynasaur: A DynamoDB ORM for Node.js
http://tglines.github.com/dynasaur/
4 comments
Thanks Jed, I was unaware of dynamo-client ... I'll make sure to go off of that (exponential back off retry sounds awesome).
How are you dealing with the difference between scan and query? DynamoDB acts quite differently to other nosql databases. It seems in the find method, you are using scan? The reason why I'm asking, is that I've run into problems with DynamoDB for a small side-project. Stuff that I took for granted from a database system that I couldn't do or change!
ie, with scan, although more resource expensive than query, you can add filters on any keys, but you can't sort any of the data. With query you can, but only on the range key you specify, which is 1 per table. Also: it can't be changed after the table is created.
Seems like difficult problems to sort out for an ORM wrapper.
ie, with scan, although more resource expensive than query, you can add filters on any keys, but you can't sort any of the data. With query you can, but only on the range key you specify, which is 1 per table. Also: it can't be changed after the table is created.
Seems like difficult problems to sort out for an ORM wrapper.
There is quite a bit to make more clear. I'd like to see how far along I can get into abstracting away the dynamodb issues.
In your scan vs. query example I'd want to duplicate the data to two indicies ... and running both through a query call. If I can get even a decent amount of consistency this way (the real challenge to the multi-index problem using this method) for small/medium data sizes it would work and still be cost effective. At larger data sizes an application will most likely know which queries it needs to execute consistently in an indexed fashion and which could be farmed out through elastic map reduce.
As mentioned here:
In your scan vs. query example I'd want to duplicate the data to two indicies ... and running both through a query call. If I can get even a decent amount of consistency this way (the real challenge to the multi-index problem using this method) for small/medium data sizes it would work and still be cost effective. At larger data sizes an application will most likely know which queries it needs to execute consistently in an indexed fashion and which could be farmed out through elastic map reduce.
As mentioned here:
https://forums.aws.amazon.com/thread.jspa?messageID=332629
Ah okay. I understand. Looking forward to how you expand it! Will be watching the project.
Crazy, I was looking for a similar tool earlier today. I've been using Mongoose for MongoDB validation/schema and wanted a similar system for DynamoDB.
Please check out the features to come, note that full test coverage is coming and feel free to ask any questions.
One thing: you should consider building this on jed/dynamo-client[1] instead of jed/dynamo. I refactored the former out of the latter last week, adding exponential back-off retry and the ability to specify custom hosts for better testability. Also, I'll be refactoring jed/dynamo myself in the near future, which will introduce breaking some API changes.