I perform a variety of actions on my model, eg.
User::destroy(Input::get('data'));
I need to test whether the above operation was sucessful or not, how would I go about doing it?
I've tried:
$deleted = User::destroy(Input::get('data'));
if (is_null($deleted) ) {
App::abort(404);
}
But to no avail.
What is recommended practice here?
If you take a look at the Illuminate\Database\Eloquent\Models destroy() method you can see that it returns the number of records deleted.
So the most elegant way to go through it would probably be:
$deleted = User::destroy(Input::get('data'));
if ( $deleted === 0 ) {
App::abort(404);
}
However if you don't care about strict comparison you could just go with:
if( ! User::destroy(Input::get('data') )
{
App::abort(404);
}
That works because 0 evaluates to false when not comparing strictly. That's also what the comments on the method say (1058-1060):
We'll initialize a count here so we will return the total number of deletes
for the operation. The developers can then check this number as a boolean
type value or get this total count of records deleted for logging, etc.
I would suggest you stick with strong comparison because the return type is just clearer, but you're free to choose whatever you want.
You should be able to just do
if(User::destroy(Input::get('data')))
{
}
This should return true or false if the user has been deleted.
Hope that helps.
Related
This may be a trivial question but I am wondering if Laravel recommends a certain way to check whether an Eloquent collection returned from $result = Model::where(...)->get() is empty, as well as counting the number of elements.
We are currently using !$result to detect empty result, is that sufficient? As for count($result), does it actually cover all cases, including empty result?
When using ->get() you cannot simply use any of the below:
if (empty($result)) { }
if (!$result) { }
if ($result) { }
Because if you dd($result); you'll notice an instance of Illuminate\Support\Collection is always returned, even when there are no results. Essentially what you're checking is $a = new stdClass; if ($a) { ... } which will always return true.
To determine if there are any results you can do any of the following:
if ($result->first()) { }
if (!$result->isEmpty()) { }
if ($result->count()) { }
if (count($result)) { }
You could also use ->first() instead of ->get() on the query builder which will return an instance of the first found model, or null otherwise. This is useful if you need or are expecting only one result from the database.
$result = Model::where(...)->first();
if ($result) { ... }
Notes / References
->first() http://laravel.com/api/4.2/Illuminate/Database/Eloquent/Collection.html#method_first
isEmpty() http://laravel.com/api/4.2/Illuminate/Database/Eloquent/Collection.html#method_isEmpty
->count() http://laravel.com/api/4.2/Illuminate/Database/Eloquent/Collection.html#method_count
count($result) works because the Collection implements Countable and an internal count() method: http://laravel.com/api/4.2/Illuminate/Database/Eloquent/Collection.html#method_count
Bonus Information
The Collection and the Query Builder differences can be a bit confusing to newcomers of Laravel because the method names are often the same between the two. For that reason it can be confusing to know what one you’re working on. The Query Builder essentially builds a query until you call a method where it will execute the query and hit the database (e.g. when you call certain methods like ->all() ->first() ->lists() and others). Those methods also exist on the Collection object, which can get returned from the Query Builder if there are multiple results. If you're not sure what class you're actually working with, try doing var_dump(User::all()) and experimenting to see what classes it's actually returning (with help of get_class(...)). I highly recommend you check out the source code for the Collection class, it's pretty simple. Then check out the Query Builder and see the similarities in function names and find out when it actually hits the database.
Laravel 5.2 Collection Class
Laravel 5.2 Query Builder
I think you are looking for:
$result->isEmpty()
This is different from empty($result), which will not be true because the result will be an empty collection. Your suggestion of count($result) is also a good solution. I cannot find any reference in the docs
I agree the above approved answer. But usually I use $results->isNotEmpty() method as given below.
if($results->isNotEmpty())
{
//do something
}
It's more verbose than if(!results->isEmpty()) because sometimes we forget to add '!' in front which may result in unwanted error.
Note that this method exists from version 5.3 onwards.
There are several methods given in Laravel for checking results count/check empty/not empty:
$result->isNotEmpty(); // True if result is not empty.
$result->isEmpty(); // True if result is empty.
$result->count(); // Return count of records in result.
I think better to used
$result->isEmpty();
The isEmpty method returns true if the collection is empty; otherwise,
false is returned.
According to Laravel Documentation states you can use this way:
$result->isEmpty();
The isEmpty method returns true if the collection is empty; otherwise, false is returned.
I think you try something like
#if(!$result->isEmpty())
// $result is not empty
#else
// $result is empty
#endif
or also use
if (!$result) { }
if ($result) { }
You can do
$result = Model::where(...)->count();
to count the results.
You can also use
if ($result->isEmpty()){}
to check whether or not the result is empty.
so Laravel actually returns a collection when just using Model::all();
you don't want a collection you want an array so you can type set it.
(array)Model::all(); then you can use array_filter to return the results
$models = (array)Model::all()
$models = array_filter($models);
if(empty($models))
{
do something
}
this will also allow you to do things like count().
You can use: $counter = count($datas);
The in_array() checks if a value exists in an array.
public function isAbsolutelyEmpty($value)
{
return in_array($value, ["", "0", null, 0, 0.0], true);
}
You want to check these two cases of count().
#1
If the result contains only a single row (one record) from the database by using ->first().
if(count($result)) {
// record is exist true...
}
#2
If result contain set of multiple row (multiple records) by using ->get() or ->all().
if($result->count()) {
//record is exist true...
}
I've been using $this->db->affected_rows() to check if updates have been successful. But this doesn't work when a user inputs the same data to be stored that is already stored (because no column is actually updated). My workaround has been to get the stored data, compare to the inputted data, update if different, return a NO_CHANGE constant if same. With JSON data, there's an extra parsing step.
Is there an easier way to check that there was no error with the update? As in, something that doesn't require getting the stored data beforehand?
If I understand correctly, you can use transactions to ensure that there was no error with the update:
$this->db->trans_start();
$this->db->query('AN SQL QUERY...');
$this->db->update('table',$array);
$this->db->trans_complete();
if ($this->db->trans_status() === FALSE)
{
// generate an error... or use the log_message() function to log your error
}
Just remember this only validates that there were no SQL errors during all the queries inside the transaction.
Here's the link for more info Code Igniter Active Record Transaction
Additionaly to the accepted answer solution you could expand the code like the following to differentiate affected_rows and trans_status results/errors.
$this->db->trans_start();
$this->db->query('AN SQL QUERY...');
$this->db->update('table',$array);
$this->db->trans_complete();
// was there any update or error?
if ($this->db->affected_rows() == '1') {
return TRUE;
} else {
// any trans error?
if ($this->db->trans_status() === FALSE) {
return false;
}
return true;
}
Mirov When we are working with codeigniter, the data only updated when there is some change in the input field's value and then the $this->db->affected_rows() will return value greater then 0.
Suppose we have two field name and email, if we try to submit the form without changing any of the field then $this->db->affected_rows() will return 0 else it will return 1.
so better approach is to use
if($this->db->affected_rows() >=0){
return true; //add your code here
}else{
return false; //add your your code here
}
my "workaround" which is pretty easy -- is to include a field that is always updated. for example if you have a field and update it with a date & time value with seconds -- then the date time seconds will always be different even if the other update values are still the same.
bonus is you have a date time in the db record for when the last update was done.
I am not sure why we can't just use this:
if ($this->db->update('table',$array) === FALSE){
// generate an error... or use the log_message() function to log your error
}
I have a custom validation rule to make sure that a non-zero price is set in a field. I have a placeholder (0.00) in the field to keep users from entering things like dollar signs. When I go to validate for a non-zero entry, however, $this->data[$this->alias]['price'] is '0.00' in my test, but the validation is working - it invalidates. But when I put in 1000.00, it's also invalidating.
One thing I can't find is what/how to return from a custom validation field to invalidate the field. Currently, the code is:
public function notZeroPrice($check){
if ($check == '0.00')
return true;
return false;
}
The docs aren't clear on the structure of $check either.
If it validates, return true. If the doesn't, return false.
However, your validation method is flawed to begin with. $check is an array if you debug it, so your method is always going to return false. Secondly, you want to test if its > 0, not just equal to '0.00'. You'll be comparing 2 string so that won't work, either.
Instead, return true if the value is greater than 0 (int). You can get it value out of the array easily by using array_shift($check);
return array_shift($check) > 0; // or something similar.
You may even get away with 'rule' => array('comparison', '>', 0), core validation.
(I'm assuming not zero for a price also means not a negative price)
So I have a fairly standard LINQ-to-Object setup.
var query = expensiveSrc.Where(x=> x.HasFoo)
.OrderBy(y => y.Bar.Count())
.Select(z => z.FrobberName);
// ...
if (!condition && !query.Any())
return; // seems to enumerate and sort entire enumerable
// ...
foreach (var item in query)
// ...
This enumerates everything twice. Which is bad.
var queryFiltered = expensiveSrc.Where(x=> x.HasFoo);
var query = queryFiltered.OrderBy(y => y.Bar.Count())
.Select(z => z.FrobberName);
if (!condition && !queryFiltered.Any())
return;
// ...
foreach (var item in query)
// ...
Works, but is there a better way?
Would there be any non-insane way to "enlighten" Any() to bypass the non-required operations? I think I remember this sort of optimisation going into EduLinq.
Why not just get rid of the redundant:
if (!query.Any())
return;
It really doesn't seem to be serving any purpose - even without it, the body of the foreach won't execute if the query yields no results. So with the Any() check in, you save nothing in the fast path, and enumerate twice in the slow path.
On the other hand, if you must know if there were any results found after the end of the loop, you might as well just use a flag:
bool itemFound = false;
foreach (var item in query)
{
itemFound = true;
... // Rest of the loop body goes here.
}
if(itemFound)
{
// ...
}
Or you could use the enumerator directly if you're really concerned about the redundant flag-setting in the loop body:
using(var erator = query.GetEnumerator())
{
bool itemFound = erator.MoveNext();
if(itemFound)
{
do
{
// Do something with erator.Current;
} while(erator.MoveNext())
}
// Do something with itemFound
}
There is not much information that can be extracted from an enumerable, so maybe it's better to turn the query into an IQueryable? This Any extension method walks down its expression tree skipping all irrelevant operations, then it turns the important branch into a delegate that can be called to obtain an optimized IQueryable. Standard Any method applied to it explicitly to avoid recursion. Not sure about corner cases, and maybe it makes sense to cache compiled queries, but with simple queries like yours it seems to work.
static class QueryableHelper {
public static bool Any<T>(this IQueryable<T> source) {
var e = source.Expression;
while (e is MethodCallExpression) {
var mce = e as MethodCallExpression;
switch (mce.Method.Name) {
case "Select":
case "OrderBy":
case "ThenBy": break;
default: goto dun;
}
e = mce.Arguments.First();
}
dun:
var d = Expression.Lambda<Func<IQueryable<T>>>(e).Compile();
return Queryable.Any(d());
}
}
Queries themselves must be modified like this:
var query = expensiveSrc.AsQueryable()
.Where(x=> x.HasFoo)
.OrderBy(y => y.Bar.Count())
.Select(z => z.FrobberName);
Would there be any non-insane way to "enlighten" Any() to bypass the non-required operations? I think I remember this sort of optimisation going into EduLinq.
Well I'm not going to ignore any question which mentions Edulinq :)
In this case, Edulinq might well be faster than LINQ to Objects, as its OrderBy implementation is as lazy as it can be - it only sorts as much as it needs to in order to retrieve the elements it returns.
However, fundamentally it still has to read the whole sequence in before it returns anything. After all, the last element in the sequence could be the first one which has to be returned.
If you're in control of the whole stack, you could make Any() detect that it's being called on your "known" IOrderedEnumerable implementation, and go straight to the original source. Note that this does create a change in the observed behaviour though - if iterating over the whole sequence throws an exception (or has any other side effect) then that side-effect would be lost by the optimization. You could argue that's okay, of course - what counts as "valid" optimization in LINQ is a decidedly tricky area.
One other possibility which is pretty horrible but which would solve this particular problem would be to make the iterator returned from the IOrderedEnumerable just take the first value of MoveNext() from the source. That's enough for the normal implementation of Any, and at that point we don't need to know what the first element is. We could defer the actual sorting until the first time the Current property is used.
That's a pretty special-case optimization though - and one which I'd be wary to implement. I think Ani's approach is the better one - just use the fact that iterating over query using foreach will never go into the body of the loop if the query results are empty.
Edit (revised): This answer adressess the issue of the query executing twice, which I believe is the key issue. See below why:
Making Any() smarter is something that only the Linq implementers can do, IMO... Or it would be some dirty adventure using reflection.
Using a class as shown below, you can cache the output of the original enumerable, and let it be enumerated twice:
public class CachedEnumerable<T>
{
public CachedEnumerable(IEnumerable<T> enumerable)
{
_source = enumerable.GetEnumerator();
}
public IEnumerable<T> Enumerate()
{
int itemIndex = 0;
while (true)
{
if (itemIndex < _cache.Count)
{
yield return _cache[itemIndex];
itemIndex++;
continue;
}
if (!_source.MoveNext())
yield break;
var current = _source.Current;
_cache.Add(current);
yield return current;
itemIndex++;
}
}
private List<T> _cache = new List<T>();
private IEnumerator<T> _source;
}
This way you keep the lazy aspect of LINQ, keep the code readable and generic. It wil be slower that directly using IEnumerator<>. There are lots of opportunities to extend, and optimize this class, such as a policy for discarding old items, getting rid of the coroutine etc. But that is beyond the point of this question I think.
Oh, and the class is not thread safe as it is now. This wasn't asked, but I can imagine people trying. I think this could be easily added, if the source enumerable has no thread affinity..
Why would this be optimal?
Let's consider two possibilites: the enumeration could containt elements or it does not.
If it contains elements, this approach is optimal as the query is
only run once.
If it contains no elements, you would be tempted
to eliminate the OrderBy and Select part of your queries, as they add
no value. But.. if there are zero items after the Where() clause, there are zero items to sort, which will cost zero time (well, almost). The same goes for the Select() clause.
What if this is not fast enough yet? In that case my strategy would be to bypass Linq. Now, I really love linq, but it's elegance comes at a price. So for every 100 times of using Linq, there typically will be one or two computations that are important to execute really fast, which I write with good old for loops and lists. Part of mastering a technology is recognizing where it is not appropriate. Linq is no exception to that rule.
Try this:
var items = expensiveSrc.Where(x=> x.HasFoo)
.OrderBy(y => y.Bar.Count())
.Select(z => z.FrobberName).ToList();
// ...
if (!condition && items.Count == 0)
return; // Just check the count
// ...
foreach (var item in items)
// ...
The query is executed just once.
but I've lost the streaming/lazy loading that's half the point of linq
Lazy loading (deferred execution), and 2 LINQ queries with disparate results cannot be optimized (reduced) to 1 query execution.
why are you not using a .ToArray()
var query = expensiveSrc.Where(x=> x.HasFoo)
.OrderBy(y => y.Bar.Count())
.Select(z => z.FrobberName).ToArray();
if there are not elements, sorting and selecting should not give much overhead. if you are sorting, then you need anyway a cache where to store the data, so the overhead .ToArray produces should not be so much.
if you decompile the OrderedEnumerable class, you find that there an int[] array containing the references is formed, so you just create by using .ToArray (or .ToList) a new reference array.
BUT
if expensiveSrc comes from a database, other strategies could be better. if the ordering can be done in the database, this would give to you quite lot of overhead because the data is stored twice.
I have a ‘featured’ attribute, which has a Yes/No select-list as the admin input. I presume that the values for Yes and No are 1 and 0, as they are for every other Yes/No list. However, if I try and filter a collection using the ‘featured’ attribute, it doesn’t work:
$feat_attribute = $_product->getResource()->getAttribute($featuredattribute)->getSource()->getOptionId(1);
But, if I make a ‘featured’ attribute with a dropdown, and write my own Yes and No, then it works as below:
$feat_attribute = $_product->getResource()->getAttribute($featuredattribute)->getSource()->getOptionId('Yes');
Anyone any ideas? I’ve also tried values as true/false, yes/no, on/off etc, but no joy.
This seems to be an old thread, but anyway I just had the same issue, I set the attribute to be visible in product listing and product view, and then apply addAttributeToFilter(feature_product_attribute, 1) for Yes/No type.
Maybe you are supposed to use '1' and '0' instead of the integer-values?
Like:
$feat_attribute = $_product->getResource()->getAttribute($featuredattribute)->getSource()->getOptionId('1');
Whenever Magento's behavior is confusing me, I start hacking on the core source (a development copy, of course) to see what it's doing and why not doing what I think it should. I haven't done much playing around with the Admin UI stuff so I don't 100% understand your question, but take a look at the getOption function
File: /app/code/core/Mage/Eav/Model/Entity/Attribute/Source/Abstract.php
public function getOptionId($value)
{
foreach ($this->getAllOptions() as $option) {
if (strcasecmp($option['label'], $value)==0 || $option['value'] == $value) {
return $option['value'];
}
}
return null;
}
I'd add some Mage::Log and/or var_dump calls in there for the values of $option['label'] and $option['value'] and see why your comparison is failing.