Req and LiftSession - aware Futures / LAFutures

[pdyraga]

Session-aware futures seems to be a recurring pain point in many projects. In the one I work, we often use Futures to lazy-load some part of a page, e.g. retrieve a list of users from a database and then apply Lift bindings on them.

In Lift3 Future template binding is straightforward but one thing is still missing: you can’t access session from them which is not so crazy as it might sound.

Continuing with users from database example, say that we retrieved a Future[Seq] of users and now we want to .map it to produce bindings that will be later bound to element. In that bindings, we’d like to use S.? to render localised user type text. Currently it’s not possible, because session will not be available in thread doing .map call.

We already have a PR addressing this issue #1730 but there are few things missing there in my opinion:

• lack of ReqVar access. I think that we should offer the same access scope as LazyLoad that we already have in Lift
• lack of session access in Future / LAFuture body
• We shouldn’t use CommonLoanWrapper for session context wrapping, because CommonLoanWrapper acts lazily which may lead to session wrapping to be done in separate thread which is too late. We need to enrich function with session access eagerly.

Sample usage of feature implemented in this PR can be:

<div id="main" data-lift="HelloWorld.render">
  Future: <span id="scala-future">Time goes here</span><br/>
  LAFuture: <span id="lift-future">Time goes here</span>
</div>

class HelloWorld {

  def render = {
    "#lift-future *" #> LAFutureWithSession.withCurrentSession {
      Thread.sleep(3000);
      S ? ("general-futureCompleted", date)
    }.map(s => s"$s in request from = ${S.request.map(_.userAgent).openOrThrowException("No request!")}") &
    "#scala-future *" #> FutureWithSession.withCurrentSession {
      Thread.sleep(1000);
      S ? ("general-futureCompleted", date)
    }.map(s => s"$s in request from = ${S.request.map(_.userAgent).openOrThrowException("No request!")}")
  }

  private def date: String = {
    new SimpleDateFormat("yyyy/MM/dd HH:mm:ss").format(new Date())
  }
}

Mailing list reference: https://groups.google.com/forum/#!topic/liftweb/qXDBuSTfWnw

[pdyraga]

cc @joescii @Shadowfiend

[farmdawgnation]

Looks like this spec is failing, which seems pretty important :)

net.liftweb.http.LAFutureWithSessionSpec

[farmdawgnation]

Finished my first (rough) pass. Looking cool, but there are some changes I'm requesting here. :)

[farmdawgnation]

While we're in here can we give ret and f a better name? 👼

[pdyraga]

I can rename ret to result (any other suggestions appreciated) but have no idea for a better name for f. I looked at Box and Option and they also use just f as param name. 🤔

[farmdawgnation]

Ditto here.

[farmdawgnation]

I'm finding this a bit hard to follow, but I'm not entirely sure why... it's entirely possible that I haven't had enough caffeine yet, but I'm flagging this anyway. ☕

[pdyraga]

I'm not a native speaker, so any improvement ideas for this scaladoc are very appreciated :)

As an "orthogonal" action, such as DB transaction I mean:

def addNewUser(name: String, surname: String, email: String): Box[User] = {
  try {
    DB.createNewTransaction()
    val user = User(name, surname, email)
    repository.persist(user)
    eventBus.publish(NewUserCreatedEvent(user.id))
 } finally {
   DB.flushTransaction()
 }
} 

^ Here, that try - finally block with all DB calls is orthogonal to business logic of this method. It shouldn't be here together with business logic code. That's a typical case when we can use Context (or CommonLoanWrapper). In Java world, it would be probably just an annotation + aspect.

[farmdawgnation]

This would read better as which is essential to do things like set up an HTTP session wrapper

[farmdawgnation]

Maybe LAFuture.withCurrentSession should be an alias to this function?

[pdyraga]

The problem is that lift-actor does not "see" lift-webkit - dependency has an opposite direction.

[Shadowfiend]

Is there perhaps something we can do with an implicit class here? Or perhaps we instead do something in S, like S.sessionFuture?

[pdyraga]

Good point. I added S.sessionFuture as an alias to LAFutureWithSession.withCurrentSession.

[farmdawgnation]

Don't we normally throw an exception if something like this attempts to access the session without a proper session context? I'd prefer we keep that behavior consistent. It feels like a situation where an exception is more or less appropriate.

[pdyraga]

I'd say that sometimes we throw an exception if method needs a session but it's not available, just like S ? do, but when something like this attempts to access the session without a proper session context we usually return a Failure. This is also similar for Req.

If you take a look at S, you'll notice that S.session returns a Box. As a result, almost all functions requiring session to be available return Box as well (e.g. findOrCreateComet, getSessionAttribute, runTemplate, eval). Functions returning Boolean in S usually return false if session is not available (e.g. legacyIeCompatibilityMode). I'd rather say that S.? is an exception here.

Similar situation is for S.request. It returns Box and as a result other methods requiring request to be available return Box as well (uri, queryString, getRequestHeader, referer).

[farmdawgnation]

👍

[farmdawgnation]

Semicolons? In Scala? :P

[pdyraga]

I find tests with chained methods more concise when putting entire action in a single line, but if that semicolon hurts your eyes badly I can remove it 😉

[farmdawgnation]

It's just that it's usually a code smell. 😬

Also, isn't this basically the same as a for-comp?

[pdyraga]

I forgot to add: semicolons removed :)

[pdyraga]

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.

[Shadowfiend]

Not as a blocker, but I wonder if we also want to make Lift's default handling of Future/LAFuture in the RHS of CSS selector transforms automatically lift the futures into a session/req context... And same for RestHelper.

[pdyraga]

Not as a blocker, but I wonder if we also want to make Lift's default handling of Future/LAFuture in the RHS of CSS selector transforms automatically lift the futures into a session/req context... And same for RestHelper.

I am not sure about this one. Although this could be handy for developers, it might also cause some bugs and confusion.

For example:

// this is fine - right side of `#>` is computed lazily so we 
// can wrap `LAFuture` with session before `SessionVar.is` gets executed
".content" #> LAFuture { SessionVar.is }

// here, `SessionVar.is` will be executed before we wrap 
// `LAFuture` in session-aware context
val future = LAFuture { SessionVar.is }
".content" #> future

The difference in code is small but serious in execution result. I'd rather prefer if users have to do

".content" #> S.sessionFuture { SessionVar.is }

or

val future = S.sessionFuture { SessionVar.is }
".content" #> future

No automatic wrapping, user has to do it explicitly, but result is predictable.

[pdyraga]

@farmdawgnation @Shadowfiend This is ready for another look.

[pdyraga]

BTW: Codacy check is not 100% accurate. I can't apply some suggested changes because the code will stop compiling. Also, I need to adjust to API that we already have, so switching the order of parameters is not an option here.

[farmdawgnation]

Sorry I lost the thread on this a little bit. Hopefully I'll have time to take a look tomorrow. Leaving this in my email inbox until I do. :)

[Shadowfiend]

Re: codacy check, yeah, I noticed. I ignored several of them and removed another few patterns. Mostly leaves the private[this] suggestions.

[Shadowfiend]

And re: auto-wrapping vs being explicit---good point, I'm 💯 on the current solution.

[farmdawgnation]

@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)

[farmdawgnation]

❤️

[farmdawgnation]

Can we break these case statements up so their result is on the next line?

[farmdawgnation]

Ditto here.

[farmdawgnation]

What happens if that's not available?

[farmdawgnation]

Ah I see. Okay, that's sensible.

[farmdawgnation]

👍

[farmdawgnation]

LGTM. @joescii @Shadowfiend Do y'all want to take a closer look at this before merge?

[Shadowfiend]

Let me try and give it another pass this week, and if I don't get to it then let's just send it in.

[pdyraga]

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 :)

[farmdawgnation]

Seems reasonable. :)

[farmdawgnation]

Ran the tests a bunch of times and didn't run into any issues. I'm merging this.

[pdyraga]

❤️