This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
I'm planning to code my own DynamoDB support, but would consider collaborating on this if there is enough interest. I'll probably end up creating the working code and then look at releasing it to the community. I particularly want to have the Spring Data REST integration.
The one thing I wish I knew in advance is whether or not there are any significant blocking issues architecturally (from the Spring side)--I am assuming that the proper interfaces and what not are there for me to fill in to get the Spring Data and Spring Data REST integration with DynamoDB that I am seeking.
From what I understand, DynamoDB inspired Riak to begin with...
Looks like I'm just going to make a my own CrudRepository template that uses @DynamoDBTable annotated model classes with the aws provided DynamoDBMapper so there's not exactly a lot of code to implement here unless implementing CrudRepository isn't sufficient for exporting as a @RestResource, but it appears to be.
It feels dirty using Spring for AWS, but unfortunately I can't afford the resources to even consider CloudFoundry as I am the dev, administrator, and operations team in one.
Looks like I also need to implement my own @EnableDynamoRepositories @interface support, RepositoryFactorySupport, and all the connected dependencies. Hopefully I'm near the end of this dependency chain...
We're not in kansas anymore! http://www.quickmeme.com/meme/3tpcjv/ At least I'm learning a lot about Spring. I'm gonna ride this bronco to the end or die trying . This would surely be trivial if I just had a bit more knowledge...
I am just going to create my own REST layer based on Spring Data interfaces and have it support Servlet 3.0 Async Methods yet return org.springframework.hateoas.Resource elements so that at least I get one major advantage vs. using the current implementation of Spring Data REST while still getting some stuff for free. The other significant thing is that the accept header content type does not support versioning, so when an entity version changes you can't handle it using the same URL as version 1 of your entity schema. The API I am making will returning multiple content types that are versioned by the accept headers so that the rest API URL never changes between versions. It should be possible to add this feature to Spring Data REST via annotations on domain models though.
It's an amazing framework and better than I could have designed, but I just don't have any more time to burn when I know I can generate the APIs that I need today--today. I will revisit this a few versions down the line though as I was working off of 1.1.0 M1 as it stood anyway.
I have to finally add a huge thank you to the author of this code and an appreciation for the work that has been done here--while I am not integrating directly with it, I am learning a great deal and am successfully using the spring hateoas classes thanks to the example it provides--and I am starting to fully appreciate the scope of what has been done here--it is impressive. Now I'll try to refrain from blogging on this thread anymore. Thank you!