PyMongo 3 compatibility.

[ajdavis]

"auto_start_request" option is gone, "max_pool_size" renamed to "maxPoolSize", "safe" is gone, "_connect" is renamed "connect".

[aburgel]

Looks like the tests are failing. Can you take a look at that? Also, are these changes backwards compatible with older PyMongos?

[jimfenton]

New installs of django_mongodb_engine are currently not working because of the PyMongo 3 compatibility issue. If this is going to take a while to get merged, can we fix the dependency to reference pymongo 2.8 in the meanwhile?

[ajdavis]

Sorry for the delay on this, I haven't had a chance to return to this and won't for a while longer. The "AssertionError: Result batch started from 101, expected 0" errors are this PyMongo 3 bug, for which we've released a fix in PyMongo 3.0.1:

https://jira.mongodb.org/browse/PYTHON-895

The other failures, I think, predate my patch so I didn't look deeply at them.

[jimfenton]

I'm seeing quite a few of those assertion errors in the test log, so that should help a lot. What does it take to get the test rerun with 3.0.1 to see what remains?

[aburgel]

@jimfenton you could run it locally to see what happens. let me know what the outcome is. i'm happy to merge this in once the tests pass and someone lets me know whether this is a backwards compatible change. If its not backwards compatible, we can bump the version number.

[jimfenton]

I patched in the relevant changes from ajdavis's fork, and my code still didn't run due to the issue with the cursor's "fields" argument having been renamed "projection" in PyMongo3 (see ajdavis's comment on issue 207 on May 2, 2015). That is one of the test failures as well so there seem to be multiple issues here that aren't addressed by 3.0.1.

[ajdavis]

I've added some more fixes to this PR:

• Deal with Cursor's "fields" versus "projection"
• Replace the obsolete "slave_okay" with Read Preference
• MongoClient.disconnect() has been removed, use the synonym close() now
• tz_aware and document_class have moved
• Recent MongoDB servers validate geo index ranges, so max=21, min=42 isn't legal any more
• Updated settings.rst to remove a bunch of obsolete guidance

AFAICT the remaining problem is the tests try to remove from a capped collection, which has never been allowed. They either never ran or never passed; I leave that up to you to sort out. =)

Peace,
Jesse

[ajdavis]

Oh and ReadPreference instances can't be copied, but Django wants to copy all options values. I fixed copying on PyMongo master. That'll be out in PyMongo 3.0.2.

[jimfenton]

For what it's worth, today's commits have my application working now. Thanks.

I'm afraid I'm a mongodb noob, so I don't know about the capped collection issue.

[jimfenton]

One more issue (let me know if I should be commenting on the mailing list instead:
Not that I have this running, I see that I'm getting warnings that the save() and remove() methods have been deprecated. This would seem like a particular problem for Django, as these methods (applied to models) are the way that things are typically saved and deleted and it would be nice to abstract the rest of the code from the choice of underlying database as much as possible. I realize it's not entirely abstracted due to the different capabilities of nonrel databases.

Should django-mongodb provide save() and remove() models, or do we want to accept that some code will need to change, if not now, soon?

[ajdavis]

PyMongo's save() and remove() are being deprecated in favor of the new
Driver CRUD API for MongoDB:

http://www.mongodb.com/blog/post/consistent-crud-api-next-generation-mongodb-drivers

However, we understand that actually removing those methods from the
driver would be a gigantic change so we have no plans to do so any time
soon.

On Thu, May 7, 2015 at 6:22 PM, Jim Fenton [email protected] wrote:

One more issue (let me know if I should be commenting on the mailing list
instead:
Not that I have this running, I see that I'm getting warnings that the
save() and remove() methods have been deprecated. This would seem like a
particular problem for Django, as these methods (applied to models) are the
way that things are typically saved and deleted and it would be nice to
abstract the rest of the code from the choice of underlying database as
much as possible. I realize it's not entirely abstracted due to the
different capabilities of nonrel databases.

Should django-mongodb provide save() and remove() models, or do we want to
accept that some code will need to change, if not now, soon?

—
Reply to this email directly or view it on GitHub
#208 (comment)
.

[aburgel]

@ajdavis @markunsworth you both have PRs for pymongo 3 compatibility. Not sure which one is more complete. Can you combine the effort into a single PR? It would be easier for me to review and merge in. Thanks!

[ajdavis]

@markunsworth @aburgel I can't devote more time to this, please feel free to use my patch however it's most useful to you. If you have any questions about PyMongo 3, however, I'm happy to answer them (I'm one of its developers). Mention me on GitHub and I'll respond as quickly as I can.

It might interest you that PyMongo 2.9 will be released in the next week or two with the intention of providing an API compatible with both PyMongo 2.8 and PyMongo 3, which should help efforts like this one. Here's PyMongo 2.9's list of changes to support a migration path from PyMongo 2 to 3:

https://jira.mongodb.org/issues/?jql=fixVersion%20%3D%202.9%20AND%20project%20%3D%20PYTHON

[aburgel]

closing this in favor of #214