Solution: Storage Adapter

[maennchen]

Based on #317, merge that PR first.

Partial Implementation of #240

This PR is currently only to track changes, do not merge until it is proven to be working with an actual storage implementation.

[maennchen]

@c-rack Do you have any idea how to capture logs in a tests setup block?

[c-rack]

@maennchen no idea, sorry

[maennchen]

@c-rack I'm going to ask around then.

[barthez]

@maennchen Hi! Have you tried capture_log from ExUnit.CaptureLog module. I have tried it and works in setup block as well.

[maennchen]

@barthez I tried using it, but I need the created values and capture_log returns the logs and not those values. (I need to pass them to the return of the setup.)

Do you know a way around that?

[barthez]

I don't know another way around it than sending a message to self:

      capture_log(fn ->
        {:ok, broadcaster} =
          start_supervised(
            {ExecutionBroadcaster, {__MODULE__, producer, TestStorage, TestScheduler}}
          )

        send(self(), {:boardcaster, broadcaster})
      end)

      broadcaster =
        receive do
          {:boardcaster, result} -> result
        end

[maennchen]

I haven’t thought of that. I don’t really like the solution, but it is way better than a jamed test log. I’ll change that.

[maennchen]

@barthez I added this little module to capture the logs:

https://github.com/c-rack/quantum-elixir/pull/313/files#diff-de2bf243c30ea309362a8386c83982a7R1

[barthez]

Looks nice. Maybe ExUnit deserves a PR? I doubt you are the only one struggling with this problem.

[maennchen]

Maybe ExUnit deserves a PR?

We'd have to write a proposal to the Mailing List. Creating PR's directly is not always appreciated.

[maennchen]

@c-rack I have one thing I really dislike about this PR. If we continue to add more storage adapters, we're soon going to have a lot of optional dependencies. (Which could cause problems even for people which do not want to use an adapter.) I would much rather split them up in multiple repositories & packages.

Would you agree to create a GitHub Orga where we could put multiple libraries together? That way we could create a separate repo for every adapter and still have them all in one place.

EDIT: I would also make the effort and migrate all the stuff if you agree.

[c-rack]

@maennchen Sure, I agree. I have created https://github.com/quantum-elixir orga and invited you as owner. It is great to see this project evolving. We should be open to everyone to contribute to this project under the C4 process and invite contributors to join the team. Feel free to migrate this project to the new orga as you like.

[maennchen]

Cool! Thank you. I‘ll figure out the details of the migration tomorrow.

[c-rack]

Ok. We should agree on a naming schema for the repos in that orga. Maybe quantum-core for the base library and quantum-storage-xxx for the xxx-storage adapters. What do you think?

[maennchen]

I agree. Do I have owner rights on that repo so that I can move it? (I know that I have them in the orga, but here I don‘t know.)

I‘ll transfer the image to the orga, rename to quantum-core. After that we should fork it back here so that the url still works.

After that we should create a new release pointing to the new urls. In the forked back repo here we should update the readme with a notice that the repo has been moved.

After all that is done, I‘ll extract the storage adapter into its own repo.

[c-rack]

@maennchen just looked and found no option to give you owner permissions on this repo, but I can do the transfer. One thing regarding the naming: if we rename the project and fork back, the URLs will still break. So maybe it is better to keep the project name as it is, ok?

[maennchen]

@c-rack You can always rename a repository.

I would do it like this:

• Transfer repo to orga
• Rename orga repo to quantum-core
• Fork orga repo to your local account
• Rename personal fork back to quantum-elixir EDIT: I have just verified, that this works with my personal fork

When you're done I'll go and change the links in the mix.exs and README.md swiftly to the new location.

This way we should break no urls and have everything named correctly.

[c-rack]

@maennchen transfer completed, fork is already renamed and I've added you as collaborator for the README changes.

[maennchen]

@pyatkov I removed your changes and put them into this repo: https://github.com/quantum-elixir/quantum-storage-ets

I will stabilize the code and add tests. After that we should be able to release the new API and the ets storage package.

[coveralls]

Pull Request Test Coverage Report for Build 775

• 53 of 53 (100.0%) changed or added relevant lines in 5 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.9%) to 94.801%

---

Totals
Change from base Build 773:	0.9%
Covered Lines:	310
Relevant Lines:	327

---

💛 - Coveralls

[maennchen]

@c-rack Would it be ok to mark this module as "experimental" and not adhere to the semantic versioning as we do with the rest of the library. (Only until it is stabilized)

[c-rack]

@maennchen that would be ok, yes

[maennchen]

@c-rack Great! Then I'm ready to release it into the wild I think.

[maennchen]

PS: I'm adding documentation as soon as it is stable.

[c-rack]

Great :)