⚠️ [ABANDONED] Rinvex Repository is a simple, intuitive, and smart implementation of Active Repository with extremely flexible & granular caching system for Laravel, used to abstract the data layer, making applications more flexible to maintain.
Home Page: https://rinvex.com
License: MIT License
Hi.
It would be cool to have some kind of more advanced filtering based on query strings or using simple classes for each filter type.
A simple example would be :
example.com/users?search=field**:operator:**value ... and so on.
Since I'm planning to use your package intensively I would be cool to have this feature.
What do you think?
I'm not you really need to inject the container into the Eloquent repository. You can just "new" up Eloquent models manually. Typically they wouldn't / shouldn't have constructor dependencies. Unless you have a strong reason for needing the container?
These methods have duplicate functionality of setCacheLifetime & getCacheLifetime methods
Still active ?
Utilize the newly introduced where, whereIn, whereNotIn methods for filtered queries.
Hi.
Just simple use case:
We want to rename a column in big application. Without criterias we also need to rename all usings of old column name in code. With criterias - we need to rename only in one place. Profit)
Also criterias give possibility to maintain database in most uniform view and reuse repeating parts of sql queries.
Cool feature to have would be transactions.
Enabled globally or per repository, maybe?
Maybe for the EloquentRepository.
What do you think?
Hey, me again ...
Wouldn't it be better to have something like this in the create, update and delete methods:
// Find the given instance
$instance = $id instanceof Model ? $id : $this->find($id);
if ($instance) {
// Fill instance with data
$instance->fill($attributes);
// Update the instance
$updated = $instance->save();
// Fire the updated event
$this->getContainer('events')->fire($this->getRepositoryId().'.entity.updated', [$this, $instance]);
}
return $updated ? $instance : $updated;So why?
Lets take this controller method as an example:
/**
* GuestsController::update
*
* Update the specified Guest in storage.
*
* @param GuestUpdateRequest $request
* @param int $id
*
* @return \Illuminate\Http\Response
*/
public function update(GuestUpdateRequest $request, $id)
{
$entity = $this->guestsRepository->update($id, $request->all());
if (is_array($entity) && $entity[0]) {
return $this->response->item($entity[1], new GuestTransformer);
}
return $this->response->errorInternal();
}I have to use indexes if from the repository I'm receiving an array ... Using my suggestion I would do like this and it would be a lot more cleaner:
/**
* GuestsController::update
*
* Update the specified Guest in storage.
*
* @param GuestUpdateRequest $request
* @param int $id
*
* @return \Illuminate\Http\Response
*/
public function update(GuestUpdateRequest $request, $id)
{
$entity = $this->guestsRepository->update($id, $request->all());
if ($entity) {
return $this->response->item($entity, new GuestTransformer);
}
return $this->response->errorInternal();
}Another use case would be when I would like to do something else with my entity. Access some other properties or pass the whole object to something else.
What do you think?
Did you chose to return an array from the methods for a particular reason?
I saw that BaseRepository has all the methods for cache managing. Would be cleaner to have the logic in another class.
SRP 😃
What do you think?
It would be nice to have an example on the readme to bind an interface to an implementation.
Give this interface:
interface UsersRepository extends \Rinvex\Repository\Contracts\RepositoryContract {}And the following implementation :
class UsersEloquentRepository extends \Rinvex\Repository\Repositories\EloquentRepository implements UsersRepository {}In a Laravel Service Provider we'd have $this->app->bind(UsersRepository::class, UsersEloquentRepository::class)
This way we don't have to new the repository implementation. Using dependency injection (i.e. injecting the UsersRepository in a controller) the IoC Container would take care of other dependencies that our app may depend on and new them up under the hood.
What do you think ?
Hi Abdelrahman Omran. Yesterday didn't had enough time to test your package and posted an issue based on code read only. Didn't mean to be rude and I'm sorry if the post sounds like it. I really appreciate your work.
Today got some time and started with a fresh laravel install and a simple database I use for development: Posts, Comments and Authors. Really simple structure with dummy data.
This is what I have and the errors that I found. Perhaps I am making some mistakes here but just followed your docs.
PostRepository
<?php
namespace App\Repositories;
use App\Models\Post;
use Illuminate\Container\Container as Application;
use Rinvex\Repository\Repositories\EloquentRepository;
class PostRepository extends EloquentRepository
{
// Instantiate repository object with required data
public function __construct(Application $app)
{
$this->setContainer($app)
->retrieveModel(Post::class)
->setRepositoryId('rinvex.repository');
}
public function getPost10()
{
return $this->findWhere(['post_id', '<=', 10]);
}
}IndexController
<?php
namespace App\Http\Controllers;
use App\Http\Requests;
use App\Repositories\PostRepository;
class IndexController extends Controller
{
private $repository;
public function __construct(PostRepository $repository)
{
$this->repository = $repository;
}
public function index()
{
$post20 = $this->repository->getPost10();
return $post20;
}
}The application throws an error:
BadMethodCallException in Builder.php line 2345:
Call to undefined method Illuminate\Database\Query\Builder::setRepositoryId()
in Builder.php line 2345
at Builder->__call('setRepositoryId', array('rinvex.repository'))
at call_user_func_array(array(object(Builder), 'setRepositoryId'), array('rinvex.repository')) in Builder.php line 1402
at Builder->__call('setRepositoryId', array('rinvex.repository'))
at call_user_func_array(array(object(Builder), 'setRepositoryId'), array('rinvex.repository')) in Model.php line 3505
at Model->__call('setRepositoryId', array('rinvex.repository')) in PostRepository.php line 16
at PostRepository->__construct(object(Application))
at ReflectionClass->newInstanceArgs(array(object(Application))) in Container.php line 779
at Container->build('App\Repositories\PostRepository', array()) in Container.php line 629
at Container->make('App\Repositories\PostRepository', array()) in Application.php line 697
at Application->make('App\Repositories\PostRepository') in Container.php line 849
at Container->resolveClass(object(ReflectionParameter)) in Container.php line 804
at Container->getDependencies(array(object(ReflectionParameter)), array()) in Container.php line 773
...
Then read about Automatic Guessing in the docs and commented the __construct() method in PostRepository.php
Another error
FatalThrowableError in EloquentRepository.php line 150:
Call to a member function toSql() on null
in EloquentRepository.php line 150
at EloquentRepository->findWhere(array('post_id', '<=', '10')) in PostRepository.php line 21
at PostRepository->getPost10() in IndexController.php line 19
at IndexController->index()
Line 150: $cacheKey = md5(json_encode([$where, $columns, $with, $lifetime, $driver, $this->model->toSql()]));
$this->model is null
Can you give me some feedback? I would like to test the improvements on the caching system.
Thanks in advance.
Cheers
As of v2.0.0 paginate() and simplePaginate() methods are returning the same results if you're not providing $page argument explicitly (but there's no info about it in documentation).
This happens because both paginate and simplePaginate methods provides their arguments to BaseRepository::executeCallback via func_get_args but its documentation says:
Note: This function returns a copy of the passed arguments only, and does not account for default (non-passed) arguments.
So, all non-passed arguments are ignored and only $perPage (which is obviously the same for every request) is provided.
As a quick-fix I did this:
use Illuminate\Pagination\Paginator;
[...]
$args = [$perPage, $attributes, $pageName, $page ?: Paginator::resolveCurrentPage($pageName)];and I'm sending this array to executeCallback instead of func_get_args.
Another fix without touching vendor code is to provide all arguments from client code:
$paginator = $repository->paginate(25, ['*'], 'page', intval($request->input('page', 1)));If first fix is ok for you, I'll create PR, just let me know.
Would you be kind enough to move the docs to the wiki? I think the readme file is getting too long. Since you are doing a great job with this package, I wouldn't want the docs to suck 😄
I know I asked you some time ago, but it would be cool to do it like this:
https://github.com/ionut-tanasa/repository/wiki
Much cleaner, imho.
If you want you can give me access and I can manage it. Or merge my wiki. I just took the readme and splitted it in sections.
Hi. good morning.
After a composer update i'm getting this error. Even on a fresh install.
Steps to reproduce:
1 - Create a new laravel project - laravel new projecttest
2 - Add rinvex/repository to composer.json - composer require rinvex/repository
3 - Add Rinvex\Repository\RepositoryServiceProvider::class to config/app.php
3 - composer update - throws the error
Any tip? It was working ok yesterday.
cheers
Hi. Thank you for this nice package. Had tried many 'repository' packages but none of them have a flexible/granular caching system.
It's ok to have a default storage and lifetime but that's not enough.
In a app I have different queries on the same repository that needs different lifetimes. The least accessed data can have a longer or infinite lifetime and can be stored in files. This cached data doesn't need to be deleted/regenerated every time the model changes.
Ex: Average product price data generated twice a month.
Ex: Product suplier list doesn't change often. This could be cached in memcached. The LRU algo from memcached doesn't cause performance issues if the this data is deleted from cache.
The most accessed data must be cached in redis with shorter lifetime.
Ex: Prices changes every week. Stock changes every day. Product descriptions are accessed every time.
A good caching system would allow to select the storage/lifetime for a specific query. If none is selected then the default is used.
Keep up the good work.
Cheers
It's recommended to decouple the repository from Laravel Eloquent for better abstraction, more adherence to the design patterns, and better consistency through dropping addGlobalScope, withoutGlobalScopes methods.
setModel, getModel, and createModelcreateModel always return a new clean model instanceSteps to reproduce
Expected result
Query is cached
Actual result
PHP Error
ErrorException in BaseRepository.php line 456:
file_get_contents(0): failed to open stream: No such file or directory
in BaseRepository.php line 456
at HandleExceptions->handleError('2', 'file_get_contents(0): failed to open stream: No such file or directory', 'C:\Work\www\projects\ae1\packages\repository\src\Repositories\BaseRepository.php', '456', array('file' => 'C:\Work\www\projects\ae1\storage\framework/cache/repository.json'))
at file_get_contents('0') in BaseRepository.php line 456
at BaseRepository->getCacheKeys('C:\Work\www\projects\ae1\storage\framework/cache/repository.json') in BaseRepository.php line 439
at BaseRepository->storeCacheKeys('App\Repositories\PostRepository', 'findWhere', '4e831f3f5eaf03c0ff46807f623cb9e2') in BaseRepository.php line 287
at BaseRepository->executeCallback('App\Repositories\PostRepository', 'findWhere', array(array('post_id' => '20')), object(Closure)) in EloquentRepository.php line 143
at EloquentRepository->findWhere(array('post_id' => '20')) in IndexController.php line 44Hit F5 or hard refresh and everything is ok.
Don't know if it is a real issue or a Windows only issue
Tested with latest php 7 (7.0.8), latest nginx on a Windows 10 box.
Cheers
Steps to reproduce
Execute two or more queries in the same request.
$x = $this->repository->setCacheDriver('redis')->findWhere(['post_id' => 10]);
$y = $this->repository->findWhere(['post_id' => 20]);Both queries are cached in redis but the second query doesn't say anything about the cache driver so it's expected to be cached in the default driver and with the default lifetime (?)
Cheers
Currently method arguments are too long.
It's recommended to move both $lifetime & $driver to setter methods. Thanks to @rsdev000 for this proposal 👍
I'm getting duplicate queries as the first issue before this refactor:
$x = $this->repository->setCacheLifetime(0)->findWhere(['post_id', '=', 10, 'or']);
$y = $this->repository->setCacheLifetime(0)->findWhere(['post_id', '=', 20, 'and']);
Queries executed
select * from post where post_id = '10'
select * from post where post_id = '10' and post_id = '20'
Updated local develop branch a few minutes ago.
Maybe you could check the number of elements in the where array before list(...) and set $boolean with a default. Otherwise there's an error if the fourth element is empty
Steps to reproduce
$x = $this->repository->setCacheLifetime(0)->findWhere(['post_id' => 10]);
$y = $this->repository->setCacheLifetime(0)->findWhere(['post_id' => 20]);Expected executed queries
select * from `post` where `post_id` = '10'
select * from `post` where `post_id` = '20'Executed queries
select * from `post` where `post_id` = '10'
select * from `post` where `post_id` = '10' and `post_id` = '20'Didn't test other find* methods
Cheers
In some cases cache isn't cleared on update! Even cache tags are being managed correctly, the actual cache not cleared!! Thanks @ninjaparade for the report 👍 Fix in progress 😉
As discussed in #53 the paginate and simplePaginate always return the first cached result for every page when the paginate() or simplePaginate() arguments are left empty.
This is expected since the default for the $page argument is null and is cached as null.
This becomes a hassle when you want the unique results for different pages, the $page argument is the last argument you can specify forcing you to specify perPage, attributes and the pageName every time you want paginated results.
illuminate/database resolves this by checking the page parameter on the request and returning the first page by default when no page parameter is provided.
Looking at the EloquentRepository all request are piped through the executeCallback method. This method handles all the fancy caching logic and returns either the results of the provided callback or the already cached results.
This is where it goes wrong, executeCallback always uses the function arguments to determine the correct cache. This works for indexes and shows but breaks for paginated results.
This happens because the cached results are returned before the Eloquent model could check if it's handling the same page as before.
To resolve this we need to add some extra logic to the paginate and simplePaginate methods. They should append the requested page parameter from the url to the function arguments when it is not the default value as specified on the method.
This can be done using the illuminate/paginator this is already a requirement when you want paginated results.
I've already got a pull request made, this issue is just for justification
Let's say I receive an array with new States that should be added to a Country. Should I use a foreach to add every single State one by one or there's a shortcut for this?
Received feedback:
A) I really like the "smart guess" feature that automatically tries to guess the Model and container if they are not set via the Repository constructor class, right now it seems to point to App\Model\GuessedName to search for the model, how about making this a config option to set the base "scan path" so we could have directories like App\Entities or just App (Which seems to be the default, considering that the User.php class is inside the root)
Laravel 5.3 will be out in a month but I'm already testing version 5.3.0-dev for a project that will start in less than 2 weeks.
I've made a PR: #22
More to come.
Cheers
While this package currently works fine with adequate granular cache, it allows cache enable/disable on two levels: per repository as a whole / per method as an individual.
Current Limitation
But what if we need say the findAll method to be cached, but we need to exclude just a single call for some reasons due to the frequency of data update of the resource or whatever reason else? This is currently not supported, and thus requires more granular and flexible cache control.
Proposed Solution
Rather than setting cached methods from the config options rinvex.repository.cache.methods, we'll move that option to the queryable method (all find* methods) so that any method call could be specified whether it's cached individually or not, with default to yes.
the v1.0.* version allowed passing an array of more than 1 column to query against, where as now we can only pass one column and an operator.
Is it possible to allow being able to query more than 1?
example
$repository->findWhere(['id' => 1, 'active' => true]);
Thinking in a RESTful way I have the following Event entity that has many Guest.
Index method:
/**
* Display a listing of the Event's Guests.
*
* @param $event
*
* @return \Illuminate\Http\Response
*/
public function index($event)
{
$eventGuests = $this->guestsRepository->whereHas('events', function ($query) use ($event) {
$query->where('event_id', $event);
});
return $this->response->paginator($eventGuests, new GuestTransformer);
}In this case it's :
/**
* @param array $relation
* @param \Closure $closure
* @param bool $paginated
*
* @return mixed|void
*/
public function whereHas($relation, \Closure $closure, $paginated = true)
{
return $this->executeCallback(get_called_class(), __FUNCTION__, func_get_args(), function () use ($relation, $closure, $paginated) {
if ($paginated) {
return $this->prepareQuery($this->createModel())->whereHas($relation, $closure)->paginate();
}
return $this->prepareQuery($this->createModel())->whereHas($relation, $closure)->get();
});
}Show method:
/**
* Display the specified Event's Guest.
*
* @param int $event
* @param int $guest
*
* @return \Illuminate\Http\Response
*
*/
public function show($event, $guest)
{
$eventGuest = $this->guestsRepository->findWhereHas($guest, 'events', function ($query) use ($event) {
$query->where('event_id', $event);
});
if (!$eventGuest) {
return $this->response->errorNotFound();
}
return $this->response->item($eventGuest, new GuestTransformer);
}For this one:
/**
* @param integer $id
* @param string $relation
* @param \Closure $closure
*
* @return mixed
*/
public function findWhereHas($id, $relation, \Closure $closure)
{
return $this->executeCallback(get_called_class(), __FUNCTION__, func_get_args(), function () use ($relation, $closure, $id) {
return $this->prepareQuery($this->createModel())->whereHas($relation, $closure)->find($id);
});
}I'd be happy to submit a PR if you like it.
While working on rinvex/fort, which uses rinvex/repository we found ourselves dealing too much with relations, which results in direct model interaction and uncached result sets, which means more queries and database hits.
I'm wondering if we can cache relations somehow on the repository level, and limit direct model interactions .. Is it possible? Is it best practice? Any other suggestions?
We could add a getter and a setter for a property on the BaseRepository and call setConnection on the model underneath.
A quick example could be $repository->setConnection('sqlsrv')->....
I'd add a default fallback configuration key to rinvex.repository.php
Hey, me again :) Just throwing some ideas here...
It would be cool to have some kind of mechanism to allow us to save / create related models.
Given this payload:
{
"user": {
"email" : "[email protected]",
"profile": {
"name": "John",
"surname": "Doe"
}
}
}Calling $repository->create($data); the following things should happen:
The profile key, obviously, would be the name of the relation on the User entity.
Same for the update(). If user.id and profile.id have values the repository would updated them accordingly.
Do you think this would be doable?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.