Synced up to 0.8.8 tag, and fixed the import as directed in #1229 #1261
Conversation
minor typos in documentation
Corrected some typos in django.rst
Fix for pickle.loads
if `dateutil` is available, use it to parse datetimes
Addition of pre_save_validation and move of pre_save to after validation.
Conflicts: AUTHORS docs/guide/signals.rst
Remove custom change tracking for ComplexBaseFields just use BaseField's one
FileField now honouring db_alias
Simplify _cls queries when only a single class
Reject email addresses where hostname ends with '.'
Removed extra closing parenthesis
No such thing as "geo_with"
Fix typo in upgrade docs
geo_within docs - fix broken code samples
Fix for broken pypi artifact
try:
from django.utils.importlib import import_module
except Exception:
from importlib import import_module
from django.utils.translation import ugettext_lazy as _Why not ImportError instead of Exception? |
|
Too much coffee this morning. |
|
@touilleMan, @thedrow, any objection to this fix to the 0.8 branch? If it is fine with you, we can merge this and release 0.8.9. |
|
I am actually not in favor of having bugfixes for older branches. Since we have no versioning for docs and so, I fear it is opening the door to many other things... We never made this in order to try to keep the focus on the still great amount of other issues we have. Also, as it is visible with the amount of commits, the 0.8.x branch was not continued (back in 2014) and I fear that these commits may just make our git history hardly readable... |
|
This seems outdated and abandoned. Please create a new PR that's rebased against the latest master if there's still something we should do here. |
|
It was a stupid simple fix pertaining to 0.8.8, because 0.10.x just kills the performance among other things... See marrow/contentment#12 for a quite large list. |
|
Ahh, thanks for linking to that ticket @apolkosnik ! It's a great summary of everything that's wrong with this package at the moment. I'll be working on addressing many of these in near future. |
|
@wojcikstefan I mention this not to spam, or to further deride. Reviewing references made to my own ticket, I noticed this one and felt I should mention I've abandoned use of MongoEngine and am now writing my own DAO layer which avoids active record patterns for the most part. (Active collection, fine, active record, that's an insane amount of complexity and rewritten behaviour to track.) I value feedback—and the documentation is still very WIP—but there may also be alternative approaches or ideas you could "steal" for MongoEngine if you desire. (It's all MIT, so go nuts. ;) As benchmarked elsewhere some time ago, the underlying storage mechanism and metaclasses (from marrow.schema) are a good chunk more performant than the ones MongoEngine currently utilizes, and MongoEngine represents a superset of marrow.schema basic declarative schema usage. Simplicity and straight-forwardness are the goals, with minimal deviation from modern PyMongo patterns and a preference for MongoDB native type storage in-memory. Simple rules can lead to very interesting complex behaviour, though. For example: QueryableQueryableQueryable. (An optimization for filtering a single condition against multiple fields simultaneously.) |
This change is