Currently the system has a few dozen models, controllers and a few hundred routes.
When carrying out any query in the database, if a certain value is found during that query, I can transform this data into another value.
An example to facilitate understanding is, when performing the query and before presenting the result, a hashtag is found, that hashtag is replaced with another value.
In this example, the difficulty is not to change the value itself (str_replace()), but to be able to intercept any of the results of queries to the database, search for this "keyword" and replace it.
But this change is only visual, it is not replacing the data in the database.
Of course I can do this on each controller, but due to the quantity, I don't think anything is viable
I think I need to somehow be able to intercept all the results of any consultation with the database and make this substitution, but I have no idea if I should use Middleware or another Laravel resource, or even that should be done by a ServiceProvider.
You can achieve this using Laravel's Resources.
You could create a HashtagResource and run all model results through it prior to utilising the data which could then look for the hashtag and replace it within the content as described.
For example, inside of the newly generated resource that wraps around your query, ie HashtagResource::collection(MyModel::all())
public function toArray($request)
{
return [
'id' => $this->id,
'title' => $this->title,
'content' => str_replace('#hashtag','#otherhashtag', $this->content)
];
}
Related
Im trying to learn GraphQL with Laravel & Lighthouse and have a question Im hoping someone can help me with. I have the following five database tables which are also defined in my Laravel models:
users
books
user_books
book_series
book_copies
I'd like to create a GraphQL endpoint that allows me to get back an array of users and the books they own, where I can pull data from multiple tables into one subfield called "books" like so:
query {
users {
name
books {
title
issue_number
condition
user_notes
}
}
}
To accomplish this in SQL is easy using joins like this:
$users = User::all();
foreach ($users as $user) {
$user['books'] = DB::select('SELECT
book_series.title,
book.issue_number
book_copies.condition,
user_books.notes as user_notes
FROM user_books
JOIN book_copies ON user_books.book_copy_id = book_copies.id
JOIN books ON book_copies.book_id = books.id
JOIN book_series ON books.series_id = book_series.id
WHERE user_books.user_id = ?',[$user['id']])->get();
}
How would I model this in my GraphQL schema file when the object type for "books" is a mashup of properties from four other object types (Book, UserBook, BookCopy, and BookSeries)?
Edit: I was able to get all the data I need by doing a query that looks like this:
users {
name
userBooks {
user_notes
bookCopy {
condition
book {
issue_number
series {
title
}
}
}
}
}
However, as you can see, the data is separated into multiple child objects and is not as ideal as getting it all in one flat "books" object. If anyone knows how I might accomplish getting all the data back in one flat object, Id love to know.
I also noticed that the field names for the relationships need to match up exactly with my controller method names within each model, which are camelCase as per Laravel naming conventions. Except for my other fields are matching the database column names which are lower_underscore. This is a slight nitpick.
Ok, after you edited your question, I will write the answer here, to answer your new questions.
However, as you can see, the data is separated into multiple child objects and is not as ideal as getting it all in one flat "books" object. If anyone knows how I might accomplish getting all the data back in one flat object, Id love to know.
The thing is, that this kind of fetching data is a central idea of GraphQL. You have some types, and these types may have some relations to each other. So you are able to fetch any relations of object, in any depth, even circular.
Lighthouse gives you out of the box support to eloquent relations with batch loading, avoiding the N+1 performance problem.
You also have to keep in mind - every field (literally, EVERY field) in your GraphQL definition is resolved on server. So there is a resolve function for each of the fields. So you are free to write your own resolver for particular fields.
You actually can define a type in your GraphQL, that fits your initial expectation. Then you can define a root Query field e.g. fetchUsers, and create you custom field resolver. You can read in the docs, how it works and how to implement this: https://lighthouse-php.com/5.2/the-basics/fields.html#hello-world
In this field resolver you are able to make your own data fetching, even without using any Laravel/Eloquent API. One thing you have to take care of - return a correct data type with the same structure as your return type in GraphQL for this field.
So to sum up - you have the option to do this. But in my opinion, you have to write more own code, cover it with tests on you own, which turns out in more work for you. I think it is simpler to use build-in directives, like #find, #paginate, #all in combination with relations-directives, which all covered with tests, and don't care about implementation.
I also noticed that the field names for the relationships need to match up exactly with my controller method names within each model, which are camelCase as per Laravel naming conventions.
You probably means methods within Model class, not controller.
Lighthouse provides a #rename directive, which you can use to define different name in GraphQL for your attributes. For the relation directives you can pass an relation parameter, which will be used to fetch the data. so for your example you can use something like this:
type User {
#...
user_books: [Book!]! #hasMany(relation: "userBooks")
}
But in our project we decided to use snak_case also for relations, to keep GraphQL clean with consistent naming convention and less effort
I am having an issue getting related models to update with scout elastic search.
$event->priceranges()->delete();
$event->priceranges()->Create([
'price' => $ticket['ticket_price']
]);
$event->update([
'show_times' => $request->showtimes,
]);
$event->searchable();
In my database I see the event and price range tables update. However when I look at my elastic search data, only data on the event has been updated. Any related models are not updated.
If I make a second update to the model and price range model, then the elastic search data shows my data from the first update I made (it is always one update behind for related models)
I tried doing
$event->pricerange->searchable()
but gives me an error because I don't have a searchable index for pricerange, I am just using my event model and its relationship to index. Is there a way to force the update other than searchable()?
Looks like your relationship is being indexed in the Event model index, correct?
Probably it's not being updated because the relationships are already loaded, and Laravel doesn't update the relationship data that is already loaded, for example:
$event = Event::with('priceranges')->first()
var_dump($event->priceranges->count()): // outputs for example 5
$event->priceranges()->create([...]);
var_dump($event->priceranges->count()): // still outputs 5, meaning that the created pricerange is not loaded
So, to fix this issue you can reload the model before calling searchable():
$event = $event->fresh();
$event->searchable();
But, note that everytime you update, the searchable method is already being called, so you will be indexing it two times on every update.
So, alternatively you can update your toSearchableArray() method in Event model to get a fresh model before returning the data (I'm assuming that you are using the babenkoivan/scout-elasticsearch-driver).
i have problem validating a bulk insertion in laravel 5 the scenario that i have is as following :
a model called department that has many employees when i save a department it may have several employee belongs to it , I'm currently loops the entire employee list and validate each one before insertion is there a way in laravel 5 validator that do this out of the box.
In Laravel 5.2 there's an easy way of taking care of this kind of problems.
Validating array form input fields is much easier in Laravel 5.2. For example, to validate that each e-mail in a given array input field is unique, you may do the following:
$validator = Validator::make($request->all(), [
'person.*.email' => 'email|unique:users'
]);
Likewise, you may use the * character when specifying your validation messages in your language files, making it a breeze to use a single validation message for array based fields:
'custom' => [
'person.*.email' => [
'unique' => 'Each person must have a unique e-mail address',
]
],
This info is clearly explained in the docs.
Source: laravel.com
To my knowledge there is not a way to do this in Laravel out of the box. By that I mean there is no method you can call or class you can use that will accomplish your goal.
You can create one though. Abstract the validation out into it's own class and use that.
I am trying to make the stored value of a polymorphic relationship more readable by other applications. Currently the polymorphic model type is stored as the FQCN of the model. Using the example in the Laravel Docs, imageable_type could be "App\Product", or "App\Staff". However, this value can be a little more difficult to manage if any non-laravel applications which aren't based on this convention and are also accessing the same database. Also, if the model FQCN ever gets refactored, you have to modify your other applications to account for the change.
Is there a way to change the type to something more consistent and readable, and then have a mapping class that maps the keys to the model? (e.g. have "product" map to "App\Product")
Yes. This is a change that was recently implemented.
Add this to your service provider (in the boot method):
Illuminate\Database\Eloquent\Relations\Relation::morphMap([
'product' => App\Product::class
]);
If you simply pass an array of model names, it'll default to using the table names:
Illuminate\Database\Eloquent\Relations\Relation::morphMap([
App\Product::class,
App\Staff::class,
]);
if you are adding morphMap method to service provider, you might want to use
'product' => \App\Product::class
( "\" before App),otherwise your namespace can be wrong.
I have a form that accepts data which will be used to create two new database table entries. The form takes both the users details and their address. The user details will be stored using the User::create(Input::all()) method into the users table, and the address details will be stored using the Address::create(Input::all()) method into the addresses table of the database.
The issue I'm currently having is that Eloquent is complaining that street, city, country etc do not exist on the users table. This is true, that data is to be used for the address side of things.
Is there any way to have eloquent ignore irrelevant data in the Input::all() array when it's passed to the create methods?
P.s. I'm aware that mass-assignment isn't a good idea, I'm only using it here to simplify my question.
Sure enough you can use $fillable array in your model to declare fields allowed for mass-assignment. I believe this is the most sufficient solution in your case.
class User extends Eloquent {
protected $fillable = [
'first_name',
'last_name',
'email'
];
}
Have you tried looking at Input::only('field1','field2',...);, or even Input::except('field3')? They should be able to accomplish what you are looking for.
Source: http://laravel.com/docs/requests
You'll have to unguard that model using these http://laravel.com/docs/eloquent#mass-assignment and then manually unset those values before you execute save(). I highly recommend using a form object or something similar to complete this kind of service for you outside of your model since it's safer and usually clearer to intended behavior.
#cheelahim is correct, When passing an array to Model::create(), all extra values that aren't in Model::fillable will be ignored.
I would however, STRONGLY RECOMMEND that you do not pass Input::all() to a model. You really should be validating and verifying the data before throwing it into a model.