Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
user system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
31 May 2013 at 09:00 UTC
Updated:
29 Jul 2014 at 22:27 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
fubhy commentedComment #3
fubhy commented#1: tempstore-if-owner-2008806-2.patch queued for re-testing.
Comment #4
fubhy commented#1: tempstore-if-owner-2008806-2.patch queued for re-testing.
Comment #5
damiankloip commentedpublic
Wrap the second part in parenthesis? I like that for readability. Really it's a matter of taste though.
Do we need the lock part here?
You're using the if($var = something()) {} pattern here but not in the other two methods, I think we should make it consistent.
We should add a bit more coverage that tests the new methods working too.
Comment #6
damiankloip commentedIt's been a while, so getting this back on track. Made the changes from my review in #5, I also added visibility to Tempstore methods - seems we might as well whilst we're there? I also converted the test to DUTB and added some assertions to check the new methods work when the user is the current owner.
I have added 2 interdiffs, purely out of laziness....sorry. The second one is just for the test assertions. That was quickest :)
Comment #7
berdirComment #8
damiankloip commentedLet's revive this one. Not sure how it got lost for so long.
Start with a reroll.
Comment #10
damiankloip commented8: 2008806-8.patch queued for re-testing.
Comment #11
damiankloip commentedAdded some unit tests for the TempStore class. Needed a couple of fixes like trying to call ->collection directly on to get the collection name, and using format_string for exception messages.
Comment #12
fubhy commentedThe additional tests look good. Thanks
All those changes are a little bit scope-creep but it really doesn't hurt to fix it right here. Not sure what the commiters think though.
Comment #13
damiankloip commentedfubhy! Where have you been all this time?! :)
Thanks. I guess they could be considered out of scope, but they are necessary for working unit tests :) So I think that is a fair trade off. Not just added in for the sake of it.
Comment #14
catchIsn't this technically setIfNotExistsAndOwner()? I can't really bring myself to suggest changing that, but it crossed my mind.
The get then delete here doesn't make me feel 100% comfortable, but there's already locking and no choice anyway.
Comment #15
damiankloip commentedI know what you mean. I think this is kind of an implicit logic that makes sense though. If you are setting IfOwner, if it doesn't exist, it owner doesn't matter so should work. I think this makes makes a nicer, more care free API for devs.
I can also appreciate what you mean about the deleting. I think this makes sense for how TempStore is currently implemented though. We need to get to be able to check the owner etc..
Comment #16
catchOK. I'll think about the implementation some more, it's not fixable without making the whole thing not a real k/v store, and not sure that's worth doing for this particular case since this ought to be low concurrency stuff anyway.
Committed/pushed to 8.x, thanks!