You're certainly right, this is the one place where it expects a Set of Long and the compiler doesn't catch this particular match expression because of type erasure.
Then maybe I'm seeing a different problem or it's a message from when the cache is built and there are no current logged in users. On Wed, May 12, 2010 at 11:58 PM, Ethan Jewett <[email protected]> wrote: > Hmmm, interesting. I was able to determine (on my machine at least) that > this chunk of code wasn't executing: > > case Full(pools: Set[Long]) if !pools.isEmpty => List( > BySql(" POOL in ( ?" + ( ", ?" * (pools.size - 1)) + " ) OR POOL IS > NULL ", > IHaveValidatedThisSQL("vdichev", "22 June 2009"), > pools.toSeq:_*) > > Because of this, the additional Pool restriction SQL was not getting > appended to the finder. The compiler wouldn't catch this because it is a > matcher, so the code just runs off to the other branch of the match, which > doesn't do anything. > > I changed Full(Set[Long]) to Full(List[Long]) in the matcher and it began > appending the required SQL. > > I've committed the change, so you can check it out of trunk and see if you > get the same results. Let me know how it goes, or if I'm totally off base. > > Ethan > > > On Wed, May 12, 2010 at 4:50 PM, Vassil Dichev <[email protected]> wrote: > >> > I think I've got a fix and I'm running through the tests now. I will >> check >> > in shortly if all goes well. Apparently the issue is that viewablePools >> is a >> > List[Long], which no longer matches Set[Long]. >> >> Hm, I don't think this is the case here. Nowhere is it specified that >> we want a Set[Long], and even if this were a problem, the compiler >> would have caught it. Check this online scala interpreter: >> >> >> http://www.simplyscala.com/interp?code=val%20s%3A%20Set[Int]%20%3D%20List%281%2C%202%2C%203%29 >> >> What happens and what Dick has also noticed is that what's inside the >> yield doesn't execute. The problem here is that User.currentUser >> returns Empty (this is an instance of Lift's Box, which is a container >> type). This is probably related to some changes in the User's >> hierarchy, but it's hard to tell why yet. >> >> At least the good news is that findMapDb is always called when it >> should be. However, in order for it to work it must know which is the >> current user- otherwise it cannot know which messages to restrict. >> >> Vassil >> >
