Support the ongoing development of Laravel.io →
Database Eloquent
Last updated 1 year ago.
0

"Now if you look only at ElasticSearch, its hard to simply integrate it as the data-provider across the application because of the different format of data, and how that data is constructed. You need to manually wire up the transformation of the data you put in elasticsearch into eloquent objects, or just avoid that, by taking the ids, and fetching models from the sql database using those. Both of these approaches are, IMO, antipattern, and cumbersome."

I fail to see how it's an antipattern or cumbersome? I see ElasticSearch as an extension to filter and find data fast. Having ElasticSearch return the actual ids and then do a look-up on them with Eloquent is an excellent and easy way to perform complex searches.

I also get the impression you're missing the point of repositories -- your repositories should ideally have interfaces and each one can be responsible for a different data store format that is agnostic to the application. You call the same methods to get the same data/models back. If you did $this->someRepository->search(array('postcode' => 'blah')); regardless of if that is doing ElasticSearch, MySQL, MongoDB, it will return the same result in a structured format of your model.

If your talking about NoSQL/formats that are generally schema-less and doesn't always translate well into a well-defined model you may have a point, but your topic is about repositories -- as per above I feel your missing the true value of having them in your application.

Last updated 1 year ago.
0

Gary provided a better answer than I could but I'd like to say that agree with him.

Your situation is probably the best reason to use repositories from the beginning the way I understand it.

My understanding of repositories (somebody please correct me if I'm wrong) is that are like a layer between your app and laravel(eloquent). I guess they work like a condom too :) I suspect that you do take a speed hit if you use them ...

So, here's a case scenario.

You build out your app with standard (errrr, by docs way -- which are actually just "a" way to use laravel) laravel methods and you decide that you're pissed at Larry for charging Android for their usage of java. So you decide to drop MySQL and want to go with Postgres or something like couch potatoes. Anyway, you got to get rid of MySQL as much as possible. Without using repositories you're headed for some hurt (hence my condom joke ;) ). You'll end up going through all your code to remove eloquent API like calls. Now, if you had that later of repositories which allow you to interface with eloquent you only have to make a some line changes to call a different repository interface that now calls Postgres or Maria. You probably could also drop eloquent and create your own PDO calls too! I suspect that using doctorine would be just as easy too with repositories.

The part I haven't figured out yet is if you can mix and match different types of storage through the usage of repositories. However, I suspect you could.

It took me a while to understand repositories too :(

I hope I'm not wrong with my understanding. I didn't study CS in university.

Last updated 1 year ago.
0

Sign in to participate in this thread!

Eventy

Your banner here too?

kapv89 kapv89 Joined 17 Feb 2014

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2024 Laravel.io - All rights reserved.