On 6/8/16 9:39 AM, Scott Marlow wrote:
[1] is an example of the MongoDB subsystem configuration (work in
progress), that specifies three different connection profiles
(mongodbtestprofile_ack, mongodbtestprofile_unack,
mongodbtestprofile_custom). It should be easy for users to specify one
of the MongoDB constants for the write-concern setting, for each of the
MongoDB profiles. Specifying a custom write-concern is also possible
(see mongodbtestprofile_custom and underlying MongoDB java driver api [2]).
In [1], I prefer the first configuration example that names the custom
write-concern element "custom-write-concern", as I thought it might be
confusing if users used the same "write-concern" name in two different
places, however, using "write-concern" for both, could be more consistent.
Should we use "custom-write-concern" or "write-concern" for the
custom
configuration element?
It comes down to a choice between:
<mongo ...>
...
<custom-write-concern name="default” w=“1” j=“true” wtimeout=“1”/>
</mongo>
OR
<mongo ...>
...
<write-concern name="default” w=“1” j=“true” wtimeout=“1”/>
</mongo>
For those not reading [1], we also can support one of the predefined
write-concern constants via:
<mongo ... write-concern="ACKNOWLEDGED">
...
</mongo>
I think it's confusing to have both an attribute and an element named
"write-concern".
Also, in the management model you are going to need to have two
attributes, one an enum for ACKNOWLEGED etc and then another for the
custom write concern. (The attributes would be declared as alternatives
to each other so the user can only configure one or the other. CUSTOM
would not be a value for the enum.)
Since you'll have two attributes in the model, probably "write-concern"
and "custom-write-concern", it will be even more confusing to call them
both "write-concern" in the xml.
Also, is the 'name="default"' setting required for
addressing specific
elements with the CLI tool? I assume this is the case but don't
remember for sure.
Can there be more than 1 custom-write-concern per profile?
If not I doubt that the config of the custom write concern should be
done via a resource. It's a complex attribute of the profile resource,
and any "name" is superfluous.
Even if you model it via a resource, if there is only one the value part
of the final type=value element of its address can be statically
defined; it doesn't need to be user configurable or stored in xml.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat