Closed nicklee1990 closed 9 years ago
Could I see some code to see exactly what you mean? I think I might have done something similar.
so for example in a lot of my repo implementations I have to do the following which isn't v DRY
/**
* @return \App\ParseClasses\Service[]|Collection
*/
public function all()
{
// TODO: Make this deal with actual pagination
$this->query->limit(1000);
$this->query->includeKey('parent'); // Sometimes I include 3-4 keys
return Collection::make($this->query->find($this->useMasterKey));
}
In reality the number of includes could be many so it'd be better to have the Abstract all method do something like:
public function all($includeKeys = [])
{
// TODO: Make this deal with actual pagination
$this->query->limit(1000);
foreach($includeKeys as $key){
$this->query->includeKey($key);
}
return Collection::make($this->query->find($this->useMasterKey));
}
Quickly knocked up but you get the idea
I was struggling with the same thing, I ended up with something like your first implementation but I did get worried that I was/would repeat myself too much.
I think your idea is pretty good. Is general enough that anyone (no matter if you have 1 key or 1000) can find this useful. I know I would.
this is now added by commit #2e557d6 but may introduce some breaking changes depending on how your contracts are set up. You should be careful to ensure that your implementations which inherit from the Abstract Parse Repo are compatible with the interface
I've ended up overriding a lot of the AbstractParseRepository methods to use the includeKey method. I think it'd make sense to an array of include Keys that defaults to null? Will be v simple, think it's worthwhile or is it just met doing this?