incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew <andrew...@gmail.com>
Subject Re: User/record filtering stuffs
Date Thu, 05 Feb 2015 14:06:11 GMT
doAs makes for nice looking code, but considering this change would break
existing code, what version would it be in?
There's also the overhead of anonymous inner classes.
On Feb 5, 2015 7:12 AM, "Aaron McCurry" <amccurry@gmail.com> wrote:

> 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