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

[Scott Marlow]

On 06/09/2016 11:34 AM, Jesper Pedersen wrote:
> 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.

+1, easier to support over time, helps us.

>
> 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
>