Spring Data MongoDB
  1. Spring Data MongoDB
  2. DATAMONGO-89

Support setting slaveOk in MongoTemplate per query

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 1.0 M2
    • Fix Version/s: 1.0 M3
    • Component/s: Repository
    • Labels:
      None

      Description

      MongoDB supports setting slaveOk() in all these places(in the order of scope): Mongo, DB, Collection, DBCursor.

      Of these, except DBCursor, everything else is shared per VM. Often decisions about whether to use slaves or not will be tied to the use-case and not to the fact that it is a certain collection.

      I would propose making that an option on the MongoTemplate instance-level. I can then have two templates and use the appropriate one for the use-case on hand. Since the template is provisioned for a Repository, the same could be done there too.

      The alternative is to add it to all find-ish methods in MongoTemplate. That would pollute the API surface area in my opinion. Also, the Repository interface will not be clean using this.

      Thoughts?

      For our usage, I'm currently extending MongoTemplate and overriding all doFind(..) methods to effect this by a custom CursorPreparer. I can submit a patch when I'm done if it is deemed generally useful for the product.

        Issue Links

          Activity

          Hide
          Mark Pollack added a comment -

          Hi,

          This also comes up with respect to write concern and there was a suggestion to have a mapping of class -> write concern, presuming that the use-case differences would be one to one with different classes. How would such a strategy work out for you with respect to slaveOk settings?

          I also agree with overloading the find methods too much, I would like to avoid that.

          Show
          Mark Pollack added a comment - Hi, This also comes up with respect to write concern and there was a suggestion to have a mapping of class -> write concern, presuming that the use-case differences would be one to one with different classes. How would such a strategy work out for you with respect to slaveOk settings? I also agree with overloading the find methods too much, I would like to avoid that.
          Hide
          Raja added a comment -

          While class-level mapping of write concern seems like a good fit, for reads it may not fir my purpose at least.

          In my case, for example, the admin users see the master data always (slaveOk=false) while non-admin users who constitute way more traffic/read requests can read slaves (slaveOk=true). It is basically the same set of classes/documents.

          Something like AbstractRoutingDataSource (from Spring Core) reinterpreted for this scenario would work better for me. Like there, supplying of slaveOk/no parameter can be strategized.

          Show
          Raja added a comment - While class-level mapping of write concern seems like a good fit, for reads it may not fir my purpose at least. In my case, for example, the admin users see the master data always (slaveOk=false) while non-admin users who constitute way more traffic/read requests can read slaves (slaveOk=true). It is basically the same set of classes/documents. Something like AbstractRoutingDataSource (from Spring Core) reinterpreted for this scenario would work better for me. Like there, supplying of slaveOk/no parameter can be strategized.
          Hide
          Thomas Risberg added a comment -

          Added an instance level flag that is used in a protected method named prepareCollection. This allows sub-classes to override with additional config options on the DBCollection if necessary.

          Show
          Thomas Risberg added a comment - Added an instance level flag that is used in a protected method named prepareCollection. This allows sub-classes to override with additional config options on the DBCollection if necessary.

            People

            • Assignee:
              Thomas Risberg
              Reporter:
              Raja
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: