Implement Ecto.Adapter.Storage

[Nathan Youngman]

ecto.create, ecto.setup, and ecto.drop fail due to the known limitation

In the current release, we do not support Adapter.Storage callbacks.

The failure looks like this:

** (Mix) Expected Ecto.Adapters.DynamoDB to implement Ecto.Adapter.Storage in order to drop storage for MyApp.Repo

Resolving this could make working with the adapter more seamless (as noted in #30)

[Darren]

Hi @nathany - I was just looking back through the outstanding issues and when I saw this one, I was reminded of some feedback that we got from some folks on Elixir Forum about this issue a while back - here's a brief outline of the conversation:

ericheikkila:

Looking for some guidance on:

“** (Mix) Expected Ecto.Adapters.DynamoDB to implement Ecto.Adapter.Storage in order to create storage for xxx”

Is there any work being done to implement Adapter.Storage for the DynamoDB adapter? I can see using Postgres or some other storage implementation for Unit Testing, but for integration/acceptance level testing I’d like to be able to hit a (local) DynamoDB instance.

Thanks in advance for pointers to where this is being worked on or why it isn’t :wink:

-Eric

michalmuskala (from the Ecto core team):

The Storage implementation is responsible for creating/dropping database. Correct me if I’m wrong, but I think that doesn’t really make sense in the context of DynamoDB.

In that case, everything should work correctly, if you don’t call the ecto.create and ecto.drop tasks.

ericheikkila:

Ah, ok, so in the DynamoDB case, even running local, dropping and creating those don’t make much sense.

In light of that, I'm going to go ahead and close this issue.

On another note, you may be interested to know that we've just published an alpha release of the adapter that has Ecto 3 support - https://hex.pm/packages/ecto_adapters_dynamodb/2.0.0-alpha.0

Thanks so much for your interest and help with this project!