anchor.diff:  
   [TIP]
   Under the hood, the
  -link:{jdbidocs}/core/statement/SqlStatement.html#bindBean-java.lang.Object-[SqlStatement.bindBean()^]
  +link:{jdbidocs}/core/statement/SqlStatement.html#bindBean-java.lang.Object-[SqlStatement.bindBean()^],
  +link:{jdbidocs}/core/statement/SqlStatement.html#bindMethods-java.lang.Object-[SqlStatement.bindMethods()^],
  +link:{jdbidocs}/core/statement/SqlStatement.html#bindFields-java.lang.Object-[SqlStatement.bindFields()^]
   and
   link:{jdbidocs}/core/statement/SqlStatement.html#bindMap-java.util.Map-[SqlStatement.bindMap()^]
   methods are just creating and binding custom implementations of
  -`NamedArgumentFinder` for beans and maps, respectively.
  +`NamedArgumentFinder` for beans, methods, fields and maps, respectively.
   
   === JdbiConfig
   
  
positive.code: void insert(@BindBean User user);
  ----
  
  Like `@BindMap`, you can qualify a bound bean with a prefix:
  
  [source,java]
  ----
  @SqlUpdate("insert into users (id, name) values (:user.id, :user.name)")
  void insert(@BindBean("user") User user);
  ----
  
  [WARNING]
  As in the Core API, neither `@BindMap` nor `@BindBean` support binding of
  nested properties (e.g. `:user.address.street`).
  
  ==== @SqlQuery
  
negative.code: Typically a single `NamedArgumentFinder` instance will provide arguments for
  several different names.
  
  In cases where neither `bindBean()`, `bindFields()`, `bindMethods()` nor `bindMap()` are a good fit, you can
  implement your own `NamedArgumentFinder` and bind that, instead of
  extracting and binding each argument individually.
  
  