incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron McCurry <>
Subject Re: Blur Platform Argument Passing
Date Thu, 25 Sep 2014 13:37:43 GMT
Let me try an example:

public class YourCommand extends Command implements IndexReadCommand<Long> {

// Normal command logic here...

  // Required by default.
  public void setTable(String table) {...}

  public void setShard(String shard) {...}

I realized it's not that sexy but it should make it very easy for the
platform to do argument checking at the controller (or even the client).
Also removes the need to annotate all the arguments at the class level.
Instead you can annotate/javadoc right on your command.

Does this help?


On Thu, Sep 25, 2014 at 9:31 AM, Tim Williams <> wrote:

> On Thu, Sep 25, 2014 at 9:06 AM, Aaron McCurry <> wrote:
> > Currently the Blur commands use arguments passed to them via an Object
> > called Args which is really just a Map that is not typed.  Then it is on
> > the command implementor to get the arguments they need out of the Args
> > object and validate that they have what they need.  Currently this works
> > but I think it has a few drawbacks.
> >
> > 1. Argument checking is done by the implementor.  I feel like the command
> > architecture should handle the check.
> >
> > 2. The argument checks are likely performed at the shard servers and so
> an
> > invalid argument is likely going to produce a lot of exceptions.
> >
> > 3. Understanding what arguments are available, what there names are, what
> > the type is, etc. is currently done through annotations on the class.  So
> > it is on the implementor to to keep them up to date.  This feels wrong.
> >
> > I prepose that we change the argument passing in the commands from the
> this
> > Args object to bean properties.  We can annotate the optional parameters,
> > use javadocs to provide documentation for the arguments, etc.
> I totally agree that the Args doesn't feel quite right and it allows
> for really late failures.  Unfortunately, I'm not sure what you mean
> by "bean properties" as a solution?  A real bean would be too
> inflexible it seems, can you give some more clues how it would work?
> I'm sure I'll get it with just one more hint:)
> Thanks,
> --tim

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