10:34 a.m.
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