django 1.4

Showing 1-33 of 33 messages
django 1.4 aburgel 3/15/12 2:51 PM
hi guys,

i'd like to open discussion of porting non-rel to django 1.4. it looks like the final version will be released any day now, so i'm happy to start things off, as i could really use prefetch_related in my app.

should we do this on top of the type-conversion-refactor branch that @wrwrwr has been working on? i really like whats been done there, but i'm not sure of the status. is it stable enough to work off of or are there still major refactorings planned?

also, jonas, i think you were maintaining the set of patches to django. how were you managing this? this might be a good opportunity to fork off the github mirror of django and then layer our patches on top of that.

--alex
Re: django 1.4 wrwrwr 3/16/12 1:44 AM
On Thu, 2012-03-15 at 14:51 -0700, aburgel wrote:
> hi guys,
>
>
> i'd like to open discussion of porting non-rel to django 1.4. it looks
> like the final version will be released any day now, so i'm happy to
> start things off, as i could really use prefetch_related in my app.
>
>
> should we do this on top of the type-conversion-refactor branch that
> @wrwrwr has been working on? i really like whats been done there, but
> i'm not sure of the status. is it stable enough to work off of or are
> there still major refactorings planned?

I'm not planning anymore major work on these branch. Possibly some
polish or updates based on reviews. I'm planning to merge them in a
couple of days.

>
>
>
> also, jonas, i think you were maintaining the set of patches to
> django. how were you managing this? this might be a good opportunity
> to fork off the github mirror of django and then layer our patches on
> top of that.
>

Good idea! Maybe with a separate branch for each ticket (plus
master/develop with all merged), so we can easily reroll patches for
Django?

>
> --alex


Re: django 1.4 aburgel 3/16/12 6:21 AM
On Friday, March 16, 2012 4:44:19 AM UTC-4, wrwrwr wrote:
On Thu, 2012-03-15 at 14:51 -0700, aburgel wrote:
> should we do this on top of the type-conversion-refactor branch that
> @wrwrwr has been working on? i really like whats been done there, but
> i'm not sure of the status. is it stable enough to work off of or are
> there still major refactorings planned?

I'm not planning anymore major work on these branch. Possibly some
polish or updates based on reviews. I'm planning to merge them in a
couple of days.

great. i'll hold off on merging db stuff until your work is done. what do you think the easiest way to do this is? merge in the existing changes and then rebase your work on top of that or start from a clean slate?
 

Good idea! Maybe with a separate branch for each ticket (plus

master/develop with all merged), so we can easily reroll patches for
Django?


 i've started on this. i forked django to django-nonrel/django and have so far ported the contrib.auth password reset changes. i'm working on file upload changes now. there are some other minor changes that i'll probably just roll up into a 'misc' branch.
Re: django 1.4 wrwrwr 3/16/12 8:17 AM
On Fri, 2012-03-16 at 06:21 -0700, aburgel wrote:
> On Friday, March 16, 2012 4:44:19 AM UTC-4, wrwrwr wrote:
>         On Thu, 2012-03-15 at 14:51 -0700, aburgel wrote:
>         > should we do this on top of the type-conversion-refactor
>         branch that
>         > @wrwrwr has been working on? i really like whats been done
>         there, but
>         > i'm not sure of the status. is it stable enough to work off
>         of or are
>         > there still major refactorings planned?
>        
>         I'm not planning anymore major work on these branch. Possibly
>         some
>         polish or updates based on reviews. I'm planning to merge them
>         in a
>         couple of days.
>        
> great. i'll hold off on merging db stuff until your work is done. what
> do you think the easiest way to do this is? merge in the existing
> changes and then rebase your work on top of that or start from a clean
> slate?

I'd just take the diff between one commit before the application of the
BitBucket changes and the tip of the type-conversion-refactor-2 branch.

There are just 2 things on that branch -- dropping "related_db_type"
changes (so probably just don't make a branch for these) and replacing
AutoField type solution (compared to clean 1.4: a few lines of new code
in the conf/__init__.py, a lengthy comment in conf/global_settings.py,
and replacing a couple of lines in the AutoField class).

>  
>         Good idea! Maybe with a separate branch for each ticket (plus
>        
>        
>         master/develop with all merged), so we can easily reroll
>         patches for
>         Django?
>        
>
>
>  i've started on this. i forked django to django-nonrel/django and
> have so far ported the contrib.auth password reset changes. i'm
> working on file upload changes now. there are some other minor changes
> that i'll probably just roll up into a 'misc' branch.


Re: django 1.4 aburgel 3/16/12 3:02 PM
a quick progress report...

i've got most of the patches separated into feature branches. i left out the 'related_db_type' and 'AutoField' changes, since wrwrwr will be handling those with his type-conversion-refactor branch.

all django tests pass. but i have not yet begun work on any of the nonrel code (djangoappengine, djangotoolbox, etc.). it looks like some saving code has moved out of Model.save_base and into the query compilers. this has made the patches to django smaller, but means we will have to do more work in our compilers.

i deviated from the original patches in one area. the non-rel dbs don't have an distinction between update and insert, so there was some code added to Model.save_base to always insert if using a nonrel backend. in order to keep track of whether its a new entity or already existing one, a property '_entity_exists' was added to the model. this was causing some trouble with the test suite because _entity_exists was set in new instances via the constructor. one of the test models didn't like that. rather than change the test model, it turns out that there was already a property of the model which did exactly the same thing as '_entity_exists'. its called '_state.added', so i removed '_entity_exists' and used '_state.added' in its place.

--alex
Re: django 1.4 Jonas H. 3/17/12 3:37 AM
First off, Alex that's really great news!

On 03/16/2012 11:02 PM, aburgel wrote:
> i deviated from the original patches in one area. the non-rel dbs don't
> have an distinction between update and insert, so there was some code added
> to Model.save_base to always insert if using a nonrel backend. in order to
> keep track of whether its a new entity or already existing one, a property
> '_entity_exists' was added to the model. this was causing some trouble with
> the test suite because _entity_exists was set in new instances via the
> constructor. one of the test models didn't like that. rather than change
> the test model, it turns out that there was already a property of the model
> which did exactly the same thing as '_entity_exists'. its called
> '_state.added', so i removed '_entity_exists' and used '_state.added' in
> its place.

The patch I submitted already does that?  Maybe you've used outdated
patches?
https://code.djangoproject.com/attachment/ticket/17340/insert-update-distinction.patch

Here's the djangotoolbox patch I once  threw together
http://paste.pocoo.org/show/566846/  It doesn't apply cleanly anymore
but you get the idea of what changed. Basically they're not passing a
list of values and a list of columns anymore but a list of objects. That
was necessary in order to get bulk_inserts to work.

Jonas

Re: django 1.4 aburgel 3/17/12 6:34 AM
On Saturday, March 17, 2012 6:37:01 AM UTC-4, Jonas wrote:

The patch I submitted already does that?  Maybe you've used outdated
patches?
https://code.djangoproject.com/attachment/ticket/17340/insert-update-distinction.patch

Here's the djangotoolbox patch I once  threw together
http://paste.pocoo.org/show/566846/  It doesn't apply cleanly anymore
but you get the idea of what changed. Basically they're not passing a
list of values and a list of columns anymore but a list of objects. That
was necessary in order to get bulk_inserts to work.


my bad. i was basing my work off of this commit:

i guess thats a bit old. are there any other major changes since then?

i will try to integrate your djangotoolbox patch. thanks for letting me know about it!
Re: django 1.4 Jonas H. 3/17/12 7:20 AM
On 03/17/2012 02:34 PM, aburgel wrote:
> my bad. i was basing my work off of this commit:
>   https://github.com/django-nonrel/django-nonrel/commit/39c56d3528d7171c4aa2360ad30ce999fd69e33b
>
> i guess thats a bit old. are there any other major changes since then?

No but that's a patch against Django 1.3. The patches against 1.4 can be
found attached to these tickets:
http://groups.google.com/group/django-developers/browse_thread/thread/a3d3c5d3bace09a6/fd268785425105e1

IIRC there's nothing left to change in Django-nonrel itself for 1.4
compatibility (besides these patches), what's left to do is fixing up
djangotoolbox and the backends.

Jonas

Re: django 1.4 aburgel 3/17/12 3:23 PM
another progress report:

i decided to port the older type conversion code to see if i could get it all to work. turns out to be pretty easy. all the tests pass on djangotoolbox and djangoappengine (except for one that looks like a timing issue). i haven't done anything on the mongo-db branch because i don't have a mongo-db server to test against.

now i'm trying to figure out how to run the full django test suite using appengine as a backend... has anyone done this before?

if anyone would like to try django 1.4 on appengine, here's what you have to do:

checkout master from django-nonrel/django and then merge in these branches:

features/non-int-autofield
features/related-db-type
features/distinguish-insert-update
features/auth-noninteger-keys
features/sql-has-results
features/auth-models
features/disable-cascade-delete
features/misc
features/content-type-extra

then checkout master from django-nonrel/djangotoolbox and django-nonrel/djangoappengine and on both merge in features/django-1.4

let me know how it works for you!

--alex
Re: django 1.4 wrwrwr 3/18/12 3:38 AM
On Sat, 2012-03-17 at 15:23 -0700, aburgel wrote:
> another progress report:
>
>
> i decided to port the older type conversion code to see if i could get
> it all to work. turns out to be pretty easy. all the tests pass on
> djangotoolbox and djangoappengine (except for one that looks like a
> timing issue).

That's really nice.

>  i haven't done anything on the mongo-db branch because i don't have a
> mongo-db server to test against.

It will need a similar bulk-inserts (SQLInsertCompiler) update and maybe
nothing more.

>
>
> now i'm trying to figure out how to run the full django test suite
> using appengine as a backend... has anyone done this before?
>

Yes and no :-) I've never got anywhere close to running all the tests --
it's even slower than with Mongo and a lot of tests will fail due to
queries not supported etc. Nevertheless, just use "python2.7 runtests.py
--testapp.settings" from the tests directory (linking all nonrel
packages into it or putting them on the Python path).

>
> if anyone would like to try django 1.4 on appengine, here's what you
> have to do:
>
>
> checkout master from django-nonrel/django and then merge in these
> branches:
>
>
> features/non-int-autofield
> features/related-db-type
> features/distinguish-insert-update
> features/auth-noninteger-keys
> features/sql-has-results
> features/auth-models
> features/disable-cascade-delete
> features/misc
> features/content-type-extra
>
>
> then checkout master from django-nonrel/djangotoolbox and
> django-nonrel/djangoappengine and on both merge in features/django-1.4
>
>
> let me know how it works for you!
>
>
> --alex


Re: django 1.4 wrwrwr 3/19/12 8:39 AM
I've merged the type conversions refactor today, so the
"features/django-1.4" branches no longer merge into "develop" (they do
into "master" as written).

I did some work on resolving conflicts (+a very basic branch for Mongo)
and moving type conversion changes to the new repo. Should I push this
as some "features/non-int-autofield-develop" /
"feature/django-1.4-develop" branches, keep it for later, or you'd
rather handle this yourself?

Mongo test suite currently has ~7 tests failing with 1.4
("test_in_bulk", "test_operation_flags", "test_unique",
"test_lazy_model_instance" x2, "test_file_with_mixin" x2).

From the toolbox and appengine tests just "test_auto_now_add" fails
(regularly) with GAE 1.4 (plus a case of a recently added
"test_foreign_key" will fail without dbindexer).

More things fail in contrib (auth, contenttypes).

Regards,
wrwrwr

On Sat, 2012-03-17 at 15:23 -0700, aburgel wrote:

Re: django 1.4 aburgel 3/19/12 1:31 PM
On Monday, March 19, 2012 11:39:16 AM UTC-4, wrwrwr wrote:
I've merged the type conversions refactor today, so the
"features/django-1.4" branches no longer merge into "develop" (they do
into "master" as written).

I did some work on resolving conflicts (+a very basic branch for Mongo)
and moving type conversion changes to the new repo. Should I push this
as some "features/non-int-autofield-develop" /
"feature/django-1.4-develop" branches, keep it for later, or you'd
rather handle this yourself?

i think we should keep separate branches so its easier to create patches to submit upstream. once we're all ready for your type conversion changes, then we can delete the pre-type-conversion feature branches and merge them all into a develop branch. i still have my ancestor query code that needs to be updated for the type conversion refactor, so i'm not ready to switch just yet.
 

From the toolbox and appengine tests just "test_auto_now_add" fails
(regularly) with GAE 1.4 (plus a case of a recently added
"test_foreign_key" will fail without dbindexer).

test_auto_now_add was failing for me too. it looks like the failure is couple of milliseconds, maybe django 1.4 has higher resolution timers? or maybe the code got slower?
Re: django 1.4 reduxdj 5/30/12 4:31 PM
By the way what's the current download linke for the latest django-non
rel please?

Thanks,
Patrick
Re: django 1.4 gyc...@gmail.com 5/30/12 5:23 PM
It's in the github repos.

you want:

django-nonrel/django-1.4 branch 1.4-nonrel
django-nonrel/djangoappengine branch features/django-1.4
django-nonrel/djangotoolbox branch features/django-1.4
django-nonrel/dbindexer branch features/django-1.4
Re: django 1.4 reduxdj 5/31/12 4:28 AM
Thanks, also is there a way to use grid-fs with django for media? That
would really solve a some problems.
Thanks,
Patrick
Re: django 1.4 reduxdj 5/31/12 5:33 AM
also, the github project needs some SEO love, this is the top rank for
me for django non rel

Django-nonrel - NoSQL support for Django | All Buttons Pressed
Re: django 1.4 Jonas H. 5/31/12 6:46 AM
On 05/31/2012 01:28 PM, Patrick Lemiuex wrote:
> Thanks, also is there a way to use grid-fs with django for media? That
> would really solve a some problems.

http://django-mongodb.org/tutorial.html#uploading-files-to-gridfs
Re: django 1.4 Andres 6/6/12 9:13 PM
Is anyone deploying this in production? The github repo says Work in progress 1.4 port, DON'T USE
Re: django 1.4 aburgel 6/7/12 6:31 AM
i'm using it. the 'DON'T USE' warning is because there are still rough edges, especially with dbindexer.
Re: django 1.4 Andres 6/7/12 9:35 AM
Thanks for the info. Is development on nonrel something that has halted or is it something people are still working on?
Re: django 1.4 aburgel 6/7/12 10:02 AM
development is definitely still alive and well. personally, i have been swamped with launching a new product (which runs on GAE and django 1.4), so i haven't been able to put in much time for the past couple of months. but that will change once this product stabilizes.

i have a few changes ready to go in (blobstore, ancestor queries, and other things). after that i want to spend some time getting GAE mapreduce to work with django's ORM.
Re: django 1.4 D X 6/7/12 6:01 PM
I'm actively developing on top of the 1.4 branch as well.  Haven't run into any showstopper issues yet.

btw, if you haven't already, vote!
Re: django 1.4 LXj 6/25/12 6:00 AM
Which repos/branches should I use to try 1.4?
Re: django 1.4 vikto...@gmail.com 11/8/12 7:04 AM
Hi,

I'm trying to get django 1.4 running with the mongodb engine. As this is my first project that would use django mongodb, it's a bit hard to understand the root of the errors and what to expect. Could someone, please, give me a helping hand by telling if it works and which branches to use?

I've tried the following:


This gives the error that was fixed in https://github.com/django-nonrel/mongodb-engine/pull/128, but seemingly not in the 1.4 branch.

and


gives a traceback I could not find in the issue tracker:

Environment:


Request Method: GET

Django Version: 1.4.1
Python Version: 2.7.3
Installed Applications:
['django_mongodb_engine',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 'django.contrib.admin',
 'storages',
 'hilbert',
 'filer',
 'django_pdb',
 'debug_toolbar',
 'django_nose']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'django.middleware.clickjacking.XFrameOptionsMiddleware',
 'hilbert.middleware.SSLRedirectMiddleware',
 'debug_toolbar.middleware.DebugToolbarMiddleware',
 'django_pdb.middleware.PdbMiddleware')


Traceback:
File "/home/akasha/.virtualenvs/django/local/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
  188.                 response = middleware_method(request, response)
File "/home/akasha/.virtualenvs/django/local/lib/python2.7/site-packages/debug_toolbar/panels/request_vars.py" in process_response
  59.                 'session': [(k, self.request.session.get(k)) for k in self.request.session.iterkeys()]
File "/home/akasha/.virtualenvs/django/local/lib/python2.7/site-packages/django/contrib/sessions/backends/base.py" in iterkeys
  115.         return self._session.iterkeys()
File "/home/akasha/.virtualenvs/django/local/lib/python2.7/site-packages/django/contrib/sessions/backends/base.py" in _get_session
  165.                 self._session_cache = self.load()
File "/home/akasha/.virtualenvs/django/local/lib/python2.7/site-packages/django/contrib/sessions/backends/db.py" in load
  23.             self.create()
File "/home/akasha/.virtualenvs/django/local/lib/python2.7/site-packages/django/contrib/sessions/backends/db.py" in create
  35.                 self.save(must_create=True)
File "/home/akasha/.virtualenvs/django/local/lib/python2.7/site-packages/django/contrib/sessions/backends/db.py" in save
  58.             obj.save(force_insert=must_create, using=using)
File "/home/akasha/.virtualenvs/django/local/lib/python2.7/site-packages/django/db/models/base.py" in save
  465.         self.save_base(using=using, force_insert=force_insert, force_update=force_update)
File "/home/akasha/.virtualenvs/django/local/lib/python2.7/site-packages/django/db/models/base.py" in save_base
  568.                 result = manager._insert([self], fields=fields, return_id=update_pk, using=using, raw=raw)
File "/home/akasha/.virtualenvs/django/local/lib/python2.7/site-packages/django/db/models/manager.py" in _insert
  203.         return insert_query(self.model, objs, fields, **kwargs)
File "/home/akasha/.virtualenvs/django/local/lib/python2.7/site-packages/django/db/models/query.py" in insert_query
  1576.     return query.get_compiler(using=using).execute_sql(return_id)
File "/home/akasha/.virtualenvs/django/local/lib/python2.7/site-packages/djangotoolbox/db/basecompiler.py" in execute_sql
  545.         key = self.insert(to_insert, return_id=return_id)
File "/home/akasha/.virtualenvs/django/src/django-mongodb-engine.egg/django_mongodb_engine/compiler.py" in wrapper
  71.             return func(*args, **kwargs)
File "/home/akasha/.virtualenvs/django/src/django-mongodb-engine.egg/django_mongodb_engine/compiler.py" in insert
  360.         for field, value in data.iteritems():

Exception Type: AttributeError at /
Exception Value: 'list' object has no attribute 'iteritems'

Quersion repeated: What's the status of mongodb support w/ django 1.4? Is it possible to get it running?

Viktor
Re: django 1.4 vikto...@gmail.com 11/8/12 8:46 AM
after my previous attempty, I've tried with django 1.3, that's the master branches


but it fails too at syncdb:

$ bin/django synbd 
Creating tables ...
Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 429, in execute_from_command_line
    utility.execute()
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 379, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/core/management/base.py", line 191, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/core/management/base.py", line 220, in execute
    output = self.handle(*args, **options)
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/core/management/base.py", line 351, in handle
    return self.handle_noargs(**options)
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/core/management/commands/syncdb.py", line 109, in handle_noargs
    emit_post_sync_signal(created_models, verbosity, interactive, db)
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/core/management/sql.py", line 190, in emit_post_sync_signal
    interactive=interactive, db=db)
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 172, in send
    response = receiver(signal=self, sender=sender, **named)
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/contrib/auth/management/__init__.py", line 41, in create_permissions
    'content_type', 'codename')[:1000000]:
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/db/models/query.py", line 107, in _result_iter
    self._fill_cache()
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/db/models/query.py", line 774, in _fill_cache
    self._result_cache.append(self._iter.next())
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/db/models/query.py", line 961, in iterator
    for row in self.query.get_compiler(self.db).results_iter():
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/djangotoolbox/db/basecompiler.py", line 335, in results_iter
    results = self.build_query(fields).fetch(
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/djangotoolbox/db/basecompiler.py", line 431, in build_query
    query.order_by(self._get_ordering())
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django_mongodb_engine/compiler.py", line 67, in wrapper
    return func(*args, **kwargs)
  File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django_mongodb_engine/compiler.py", line 104, in order_by
    if order.startswith('-'):
AttributeError: 'tuple' object has no attribute 'startswith'

or with runserver:

Environment:


Request Method: GET

Django Version: 1.3.1
Python Version: 2.7.3
Installed Applications:
['django_mongodb_engine',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.messages',
 'django.contrib.staticfiles',
 'django.contrib.admin',
 'storages',
 'hilbert',
 'django_pdb',
 'debug_toolbar',
 'django_nose']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'hilbert.middleware.SSLRedirectMiddleware',
 'debug_toolbar.middleware.DebugToolbarMiddleware',
 'django_pdb.middleware.PdbMiddleware')


Traceback:
File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
  178.                 response = middleware_method(request, response)
File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/debug_toolbar/panels/request_vars.py" in process_response
  59.                 'session': [(k, self.request.session.get(k)) for k in self.request.session.iterkeys()]
File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/contrib/sessions/backends/base.py" in iterkeys
  138.         return self._session.iterkeys()
File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/contrib/sessions/backends/base.py" in _get_session
  195.                 self._session_cache = self.load()
File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/contrib/sessions/backends/db.py" in load
  20.                 expire_date__gt=datetime.datetime.now()
File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/db/models/manager.py" in get
  132.         return self.get_query_set().get(*args, **kwargs)
File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/db/models/query.py" in get
  346.         num = len(clone)
File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/db/models/query.py" in __len__
  82.                 self._result_cache = list(self.iterator())
File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django/db/models/query.py" in iterator
  275.         for row in compiler.results_iter():
File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/djangotoolbox/db/basecompiler.py" in results_iter
  335.         results = self.build_query(fields).fetch(
File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/djangotoolbox/db/basecompiler.py" in build_query
  430.         query.add_filters(self.query.where)
File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django_mongodb_engine/compiler.py" in add_filters
  160.                 self.add_filters(child, query=subquery)
File "/home/akasha/.virtualenvs/django-mongodb/local/lib/python2.7/site-packages/django_mongodb_engine/compiler.py" in add_filters
  168.             column, lookup_type, db_type, value = self._decode_child(child)

Exception Type: ValueError at /
Exception Value: need more than 3 values to unpack
Re: django 1.4 aburgel 11/8/12 8:50 AM
On Thursday, November 8, 2012 10:04:50 AM UTC-5, vikto...@gmail.com wrote:
Quersion repeated: What's the status of mongodb support w/ django 1.4? Is it possible to get it running?

I don't think the 1.4 branches of django-nonrel work with mongodb, only with appengine. It wasn't too hard to get the appengine code upgraded, so if you want to give it a shot... 
Re: django 1.4 Josh 12/2/12 12:41 AM
I'm getting the same error as Viktor. I thought 1.3 was supposed to work with mongo. Any suggestions?

--Josh

On Thursday, March 15, 2012 3:51:41 PM UTC-6, aburgel wrote:
hi guys,

i'd like to open discussion of porting non-rel to django 1.4. it looks like the final version will be released any day now, so i'm happy to start things off, as i could really use prefetch_related in my app.

should we do this on top of the type-conversion-refactor branch that @wrwrwr has been working on? i really like whats been done there, but i'm not sure of the status. is it stable enough to work off of or are there still major refactorings planned?

also, jonas, i think you were maintaining the set of patches to django. how were you managing this? this might be a good opportunity to fork off the github mirror of django and then layer our patches on top of that.

--alex
Re: django 1.4 D X 12/2/12 5:02 PM
I've been working on the app engine side, I haven't touched the mongo db side.

It looks like you're trying to use contrib.auth permissions, which use many-to-many relationships, which generally don't work well in django-nonrel.

Here's my suggestions:
- Disable the admin interface, comment out 'django.contrib.admin' from the INSTALLED_APPS, this is probably what's trying to use models with permissions.

I don't use the admin interface, so I don't have this problem.  I've noticed others have tried to deal with it, I think this project is supposed to help that problem:

If you're already using that, um, then I dunno.
django 1.4 Holografix 12/26/12 12:46 AM
Hey nonrel contributors, any reason why you guys are not giving mongodb much attention?

Is it because GAE takes care if the PaaS and the DB so you get more out of your effort?

I love Django and would really like to be able to use MongoDB on it.

To Vikto and the other guys interested in Mongo, you can get the admin working if you decouple auth from Mongo by using a db router. The docs have instructions on how to do this.

It's working beautifully in dev but I don't even want to think I the mess when I start testing on Heroku lol!

Re: django 1.4 aburgel 12/26/12 8:34 AM
On Wednesday, December 26, 2012 3:46:16 AM UTC-5, Holografix wrote:
Hey nonrel contributors, any reason why you guys are not giving mongodb much attention?

Is it because GAE takes care if the PaaS and the DB so you get more out of your effort?

I'll speak for myself on this one, but I suspect it applies to others as well. I use django-nonrel for my work, which runs on GAE. Most of my contributions come from things I needed for work. I occassionally have time to work on other general stuff, but not much.

So the reason mongodb isn't getting enough love is probably because not many people are using it, or those that do use it haven't found it necessary to make changes.

The django ORM is not easy to understand, so it can be a bit intimidating to dive into the code. But most of the hard stuff has already been written, so upgrading the django-nonrel mongodb code to work with django 1.4 is probably not that hard. I think its mostly adapting to changed interfaces and a few other minor tweaks (at least thats what it was like for the GAE code). I'm happy to help out if needed, but I can't do it on my own since I don't have a mongodb setup to play with.

--Alex
Re: django 1.4 Sepero 12/26/12 10:18 AM
Lack of developers for MongoDB. Heroku would be doing themselves a big favor if they had a developer contributing to this effort.
Re: django 1.4 D X 12/26/12 5:11 PM
There was a move earlier this year to get django-nonrel integrated into django.

The django guys shot down that idea, you can look through the django mailing list archives to piece together why.
I think the mongodb guys gave up after that, I haven't seen any contributions from them after that.

On the GAE side, it seems like devs like aburgel who are using django-nonrel are the ones maintaining it.

So if you get it 1.4 to work on MongoDB, maybe other users will jump on board.



On Wednesday, December 26, 2012 3:46:16 AM UTC-5, Holografix wrote:
Re: django 1.4 Scott Lyons 12/26/12 1:00 AM
Personally I had given up much hope to using the latest versions with mongo, opting to use Flask instead. But if it's decently stable maybe I should take a stab at seeing what needs doing. Not sure if the the new aggregation framework is being used yet by nonrel.
More topics »