Limited use of DatabaseConnectionGenerator#getConnection

[f4lco]

Given the following algorithm

public class BugAlgorithm implements
    InclusionDependencyAlgorithm,
    DatabaseConnectionParameterAlgorithm {

  @Override
  public void setDatabaseConnectionGeneratorConfigurationValue(String identifier,
      DatabaseConnectionGenerator... values) {

    if (values[0].getConnection() == null) {
      throw new IllegalStateException("connection not available");
    }
  }

  @Override
  public ArrayList<ConfigurationRequirement<?>> getConfigurationRequirements() {
    return new ArrayList<>(asList(new ConfigurationRequirementDatabaseConnection("DB", 1)));
  }
  
  // remainder omitted - empty methods; at most debug output
}

It turns out that the connection is indeed null. This is due to the fact that once a DefaultDatabaseConnectionGenerator crosses process boundaries, it looses its non-serializable connection object. Internally methods like generateResultSetFromSql check for a missing connection and re-establish it as needed, meaning the connection is only available if at least one query was fired through the dedicated methods. If the connection should be accessed before that one is out of luck.

Possible workaround: fire a no-op SQL query like select 1 union select 1 in order to be able to access the connection.

Possible fixes: re-establish connection as early as possible after deserialisation; or make the getter have the same side effect as the query methods.

This possibly also affects the usefulness of the new accessor for DatabaseConnectionGenerators in TableInputGenerators in #384.

[thorsten-papenbrock]

I suggest that you let the getter establish a connection if no connection exists.
Can you make a pull request for that small change so to get this blocking issue fixed as soon as possible?

[maxifischer]

Fixed with d5d02b7