Uploaded image for project: 'Python Driver'
  1. Python Driver
  2. PYTHON-136

Make master_slave_connection less of a special case

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1
    • Component/s: None
    • Labels:
      None
    • # Replies:
      4
    • Last comment by Customer:
      false

      Description

      should be easier for others to implement similar things on their own, and better integration will avoid some of the issues that pop up w/ this now and again.

        Activity

        Hide
        daysleeper Eytan Daniyalzade added a comment -

        Could you please provide more information on this bug? pymongo master_slave_connection.py has references to this bug in multiple places, e.g. tz_info being hardcoded to true, so i am wondering how this bug relates to that.

        Show
        daysleeper Eytan Daniyalzade added a comment - Could you please provide more information on this bug? pymongo master_slave_connection.py has references to this bug in multiple places, e.g. tz_info being hardcoded to true, so i am wondering how this bug relates to that.
        Hide
        behackett Bernie Hackett added a comment -

        Mike Dirolf no longer works for 10gen but I think what he probably meant was that the master_slave_connection shouldn't even be necessary. We currently promote the use of replica sets, not master/slave setups. The Connection class doesn't currently support the distributed reads provided by master_slave_connection but it should.

        How this all relates to tz_aware I don't know. tz_aware is a setting of the Connection instances the MasterSlaveConnection instance is created with. I suspect that property was added because it exists in Connection as well. tz_aware=True was once the default when you instantiate Connection, but that is no longer true. It should probably be hard coded to False in MasterSlaveConnection instead.

        Show
        behackett Bernie Hackett added a comment - Mike Dirolf no longer works for 10gen but I think what he probably meant was that the master_slave_connection shouldn't even be necessary. We currently promote the use of replica sets, not master/slave setups. The Connection class doesn't currently support the distributed reads provided by master_slave_connection but it should. How this all relates to tz_aware I don't know. tz_aware is a setting of the Connection instances the MasterSlaveConnection instance is created with. I suspect that property was added because it exists in Connection as well. tz_aware=True was once the default when you instantiate Connection, but that is no longer true. It should probably be hard coded to False in MasterSlaveConnection instead.
        Hide
        auto auto (Inactive) added a comment -

        Author:

        {u'login': u'behackett', u'name': u'behackett', u'email': u'bernie@10gen.com'}

        Message: MasterSlaveConnection.document_class PYTHON-136

        Document class is now configurable as in Connection
        and ReplicaSetConnection.
        Branch: master
        https://github.com/mongodb/mongo-python-driver/commit/020318251939bf2a37e691817dbd02d146e7d01e

        Show
        auto auto (Inactive) added a comment - Author: {u'login': u'behackett', u'name': u'behackett', u'email': u'bernie@10gen.com'} Message: MasterSlaveConnection.document_class PYTHON-136 Document class is now configurable as in Connection and ReplicaSetConnection. Branch: master https://github.com/mongodb/mongo-python-driver/commit/020318251939bf2a37e691817dbd02d146e7d01e
        Hide
        behackett Bernie Hackett added a comment -

        tz_aware was made configurable for PYTHON-279

        Show
        behackett Bernie Hackett added a comment - tz_aware was made configurable for PYTHON-279

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since reply:
              5 years, 25 weeks, 5 days ago
              Date of 1st Reply: