Req and LiftSession - aware Futures / LAFutures #1813
Session-aware futures seems to be a recurring pain point in many projects. In the one I work, we often use
Continuing with users from database example, say that we retrieved a
We already have a PR addressing this issue #1730 but there are few things missing there in my opinion:
Sample usage of feature implemented in this PR can be:
Mailing list reference: https://groups.google.com/forum/#!topic/liftweb/qXDBuSTfWnw
Lift 3 allows to bind Future / LAFuture instance to template elements easily. Still, when Future gets transformed with one of its map/flatMap/etc methods or when Future body gets executed we don't have an access to current Req or LiftSession. This issue seems to be recurring between various projects using Lift framework. This commit brings request and session-aware futures. It allows to create such a type of LAFuture or decorate Scala's Future instance so that Req and LifSession parameters can be accessed from it.
I've run all specs created in this PR dozen of times but, as usually, with tests running code concurrently, they can give different results on another machine. Good that it failed here, not later. I think I eliminated all possible issues. Some of them were related to the possible race condition that we discuss here https://groups.google.com/forum/#!topic/liftweb/V1pWy14Wl3A and some of them were my fault in implementation.
Anyway, it's ready for another chance now.
I am not sure about this one. Although this could be handy for developers, it might also cause some bugs and confusion.
The difference in code is small but serious in execution result. I'd rather prefer if users have to do
No automatic wrapping, user has to do it explicitly, but result is predictable.
farmdawgnation left a comment
@pdyraga Sorry for the delay in getting this feedback to you. I think we're down to minor stylistic details. I think I have finally groked the code enough to understand what's going on. It only took me two months to find the time in my schedule to get Lift in my brain for a bit.
(In fairness, I did get marries in that time frame so shrug haha)
Folks, I'd appreciate if you could clone this branch and run modified tests on your boxes before merging. They pass on my box, they pass on Jenkins, but since these are tests operating on multiple threads having additional checks would boost my confidence about them :)