[wildfly-dev] A few questions about the NoSQL MongoDB client subsystem configuration...

[Jesper Pedersen]

Hi,

On 06/09/2016 06:27 AM, Gunnar Morling wrote:
> My concern with the current proposal and its usage of dedicated
> elements/attributes for specific options such as write concern is that it
> easily leads into a catch-up game with datastore vendors as they keep
> adding new options. That might create a constant effort for maintaining
> this subsystem.
>

Yes, that is def something to take into account, as there is no common 
functionality across all the stores.

> How about having a more generic approach which only has typed elements for
> common properties/settings such as user, password, database name and then
> allows to set custom things as part of the connection URL:
>
>      <subsystem xmlns="urn:jboss:domain:nosql:1.0">
>          <nosql-datasource jndi-name="java:jboss/nosql/mongodb_test">
>
> <connection-url>nosql:mongdb:localhost:27017,otherhost:27017/somedatabase?writeConcern=ACKNOWLEDGED&readPreference=MAJORITY&...</connection-url>
>              <security>
>                  <user-name>bob</user-name>
>                  <password>secret</password>
>              </security>
>          </datasource>
>      </subsystem>
>
> Here, the connection-url would be analyzed to load the right driver and
> pass any configured settings to it.
>

The problem I see with that approach is that some stores doesn't have a 
URL concept, so that part will be foreign to those users.

Also the parameters may need to be applied to various "levels" in the 
setup. It would be better to scope those as close to component in 
question, like we have the pooling configuration under <pool> in 
:datasources:.

Parsing the URL w/ configuration could also lead to more configuration 
errors in general.

> While compact, that URL syntax might be confused with existing URI schemes
> of specific stores, so an alternative might be this (a bit more verbose,
> though):
>
>      <subsystem xmlns="urn:jboss:domain:nosql:1.0">
>          <nosql-datasource jndi-name="java:jboss/nosql/mongodb_test">
>              <driver>mongodb</driver>
>              <end-points>localhost:27017,otherhost:27017</end-points>
>              <database>somedatabase</database>
>              <security>
>                  <user-name>bob</user-name>
>                  <password>secret</password>
>              </security>
>              <properties>
>                  <property name="writeConcern">ACKNOWLEDGED</property>
>                  <property name="readPreference">MAJORITY</property>
>              </properties>
>          </datasource>
>      </subsystem>
>

Yes, I agree that this would be easier to support over time. And the 
<properties> element could be scoped under the NoSQL components that 
needs it.

That is how <connection-property> works for :datasources:, as we can't 
change the subsystem configuration for each patch release of a JDBC driver.

> Both alternatives don't address custom write concerns, but I think you
> foresee CDI producer methods for more advanced customizations, so that
> might be fine. That'd also be needed for some other non-primitive options
> (dbDecoderFactory, codecRegistry etc.), unless you provide a way to
> configure classes here and have them instantiated.
>
> These more generic approaches will make it more robust towards new options
> being added, but of course you also loose type-safety and I suppose
> usability in the console which might provide dedicated editors for real
> types such as boolean etc.

True, but I think that properties that needs a set- are likely important 
enough to expose directly in the configuration as an element/attribute.

And that comes down to what each store supports - for JCA we just got a 
'supportsDynamic' concept in JCA 1.6, but that doesn't necessarily 
translate to JDBC drivers and their DataSource deployments...

Best regards,
  Jesper