Using different repos for different models

[assembler]

What if I want to use different repos for different models? Some of my models can be persisted in postgres, while some retrieved via api, some stored in redis, yet others stored in dynamodb. As the app grows, I want to be able to change between persistance strategies on model basis in order to optimise performance, or extract some portions of it as external services.

Repo solution, as you have put it, is designed as a service which uses single shared implementation (strategy) for all the models. Am I missing a way to make this per-model based?

[ahawkins]

@assembler I have done this in my repository implementation. This why the internal implementation use a mapper. So you'd create a post mapper, comment mapper, etc. I'm working on improving this story. I haven't need to do this yet, so I'm working purely in abstracts. Can you suggest some changes on how this can be easier.

I got an email about this same question the other day. Here's my reply:

Also, if I wanted to use different adapters per repository, should I override self.backend in each class that I wanted to use a different adapter?

Depends, I usually use on repository then implement different logic per class inside the large context. If you do want to break it up separately then you should override self.backend like you suggested. That should return a repository instance.

Here’s a gist that may help you.

https://gist.github.com/ahawkins/11260461

[assembler]

Hey, good example in that gist. Naming is a bit confusing: having "store" (StatStore) to inherit from "repo" (BaseRepo) to be used by "repo" (StatRepo), but the overall idea is good.

I'm doing some research on the topic for past few months. I'm weighting pros and cons of repo/query abstractions, versus using plain data mappers in their original form. Sequel (gem) is already a "repository implementation" in sense that it provides "an object oriented view of your datastore", so building a repo on top of a repo seems kinda redundant to me. The only real benefit i see here is testing, but by hiding data access calls (to sequel) behind a mapper class, we can stub the mapper methods and execute our tests in isolation. I don't have any strong opinions on this, i'm just pointing out the current state of my research.. which might change as well as it often does :)

[fishermand46]

This link shows a pretty cool syntax:
Repository.register(:user, MemoryRepository::UserRepository.new)
It allows you to associate a model with a repo. Although, in our case, we would want to associate a repo with another repo. Something like:
Chassis.repo.register(UserRepo, Chassis::MemoryRepo)
This would say, whenever you use an instance of the UserRepo, delegate to the Chassis::MemoryRepo.