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

[Gunnar Morling]

Hi,

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.

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.

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>

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.

--Gunnar




2016-06-08 22:18 GMT+02:00 Brian Stansberry <brian.stansberry at redhat.com>:

> On 6/8/16 9:44 AM, Jesper Pedersen wrote:
> > On 06/08/2016 10:39 AM, Scott Marlow wrote:
> >> For those not reading [1], we also can support one of the predefined
> >> write-concern constants via:
> >>
> >> <mongo ... write-concern="ACKNOWLEDGED">
> >>     ...
> >> </mongo>
> >>
> >
> > I would choose this approach, and support the predefined constants.
> >
> > Exposing MongoDB internal API details in the configuration seems to be
> > overkill, and put extra effort on your part when they change the API.
> >
>
> This is good input. If this ends up in WildFly or EAP, we have stringent
> compatibility guarantees, so be cautious about exposing things in your API.
>
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160609/f26a0494/attachment.html