-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inavalidation Problems since last version #91
Comments
Thanks, @jetwes , I will look into this. Have you been able to see any kind of pattern that might be causing this? Are you using the cache cool down option? |
No, i'm not using the cool down option. I cant'see a pattern at the moment. I get an additional info: I'm using redis 2.0.8 (latest) and a seperate db for model caching |
It seems a bit like if the queries are hit in short time the error occurs (just a guess) - but i'm not using cool down. I have about 170 users that are working within this app (all at the same time, it's a business portal for managing mobile phone shops) averaging about 90.000 Request per 24h.. |
Another example: Error: The errors don't accur on every requests - but a couple of times in a minute... |
@jetwes thanks again for the details. It almost sounds like different users are overriding the query cache in different circumstances, which if true, means that some keys are not granular enough, and even though you specified `first()1st it's actually returning the collection. |
@jetwes I had another thought. If you could see if you can get this error to happen again in your dev environment, would you be able to look at the collection that it errors on, and see what query created that collection? If so, that would be the smoking gun we need to identify the source of the problem. In the mean while I am writing a few more tests to cover some scenarios I can think of. |
ok, i'll have a look at it, later |
Ok - seems that the mess is on my side. I have a couple of old queries ending ->get()[0]; instead of using ->first(); But there's a strange thing. php artisan modelCache:flush --model=Portal\Models\Sale
|
Hi @jetwes, awesome, thanks for researching this further. Try the following on the commandline: |
nope - same error - on all my models. I can't flush the model from the command line.. did you change the way you return collections in the last couple of versions? Just asking because my get()[0] queries were ok in the old version... |
Thanks for checking. I will look into why models can't be flushed from the command-line and see if there is an edge-case. The way data is stored in the cache changed, but it shouldn't affect being able to access an index on a collection (since get should always return a collection, which is stored in cache). Could you provide me with a full query that you are trying to run, ending in In the mean time, I would highly recommend using a dedicated cache store for model-caching, if you haven't already done so. You can then flush the cache for models without affecting your normal cache, by simply omitting the model options on the command-line: |
i'm using redis in a seperate database. An example Query: I already refactored most of the old queries to first() - i will monitor this in the next days.. |
Thanks! I will try to make a test case this evening and report back |
Also, you could simplify your query, by using $saleItem = SaleItem::find(Request::input('id')); |
Also, I covered the process I went through here, let me know if I missed something: https://t.co/CHKiHkfYGz I would probably suggest opening a new issue if you find a problem, as the original issue on this one has been resolved, and we're working on secondary things now. :) |
I am able to replicate the flushing issue ... working on that separate from this issue |
Fix for model flush command will be in the next release in a few minutes. :) |
Thank you! |
Is Shop also using Cachable? In your view, can dump out the user I'd in the loop, before you display the main_shop? Could you post a demo repo with just the view, route, and controller needed to get this specific page to work? That way I could try to replicate the problem. I suspect the issue lies somewhere other than in the query itself. |
by the way - the user is not cachable. |
i posted it to a repo - you got an invite link. Its straighforwarded - i uploaded vendor, too. so just clone it and you are ready. a sql is inside the migrations folder for quick generetion of the db tables. |
Got the invite, thanks! Will take a look at it tomorrow :) |
@jetwes I started installing the repo, but it appears the migration folder is missing. Could you add that for me? :) Thanks! |
oh sorry - i'm looking for it this evening - i was sick the last couple of days - sorry for the delay |
Hope you feel better - gute Besserung! |
thank you mike - danke schön ;) |
@jetwes I fixed an issue with |
@mikebronner it seems to work as expected! I will have a look on the logs today - but it's looking good at the moment! |
Closing for now. If it crops up again, please open a new issue. :) |
I just updated to the latest version and now i have strange errors - maybe something todo with invalidation. (or not invalidating)
Example:
In my SalesController i prepare to add another product to the basket.
$saleItem = SaleItem::where('id','=',$request->get('id'))->first(); $product = Product::where('id',$request->get('product_id'))->first(); $saleItem->product_id = $product->id;
Now sometimes - mostly when more than one product is in the basket i get this error:
Property [id] does not exist on this collection instance.
(Regarding the line $product->id)If i disable the cache everything is ok. Before i updated to the current version everything was fine, too.
What could be the problem over here. I have the same error on different Controllers - not only regarding products.. I disabled the whole cache now - because i'm getting many errors like these...
PHP 7.1
Laravel 5.5
latest package version
The text was updated successfully, but these errors were encountered: