incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron McCurry <amccu...@gmail.com>
Subject Re: User/record filtering stuffs
Date Thu, 05 Feb 2015 12:11:00 GMT
We could also support the "doAs" method call similar to Hadoop's API.  So
something like:

// Class member variable
private Iface client = BlurClient.getClient();

// Inside a method.
...
User user = new User("user1", null);

List<String> tableList =
user.doAs(new PrivilegedExceptionAction<List<String>>() {
  public List<String> run() {
    return client.tableList();
  }
};


Instead of:


User user = new User("user1", null);
List<String> tableList;
try {
  UserContext.setUser(user);
  tableList = client.tableList();
} finally {
  UserContext.reset();
}


Thoughts?

Aaron



On Wed, Feb 4, 2015 at 7:45 PM, Tim Williams <williamstw@gmail.com> wrote:

> I've been giving the new record filtering stuff a spin today and I've
> found bits of it non-obvious.  Mainly with having both o.a.b.user.User
> and o.a.b.thrift.generated.User and setUser and UserContext.setUser.
> It turns out the UserContext gives the behavior I expected
> (implementing a BlurFilterServer) but it's not clear why we need the
> seemingly duplicitous classes/services around?  From a user's
> perspective, btw, the static setter approach feels uncomfortable.  I
> know, "uncomfortable" isn't very constructive - I'm hoping to offer
> that when my question is answered:)
>
> Thanks,
> --tim
>

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