3:29 p.m.
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