incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <esjew...@gmail.com>
Subject Re: Pool messages are displayed where they shouldn't
Date Wed, 12 May 2010 20:58:06 GMT
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 <vdichev@apache.org> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message