Re : Re: #1342 Allow customization of MAX_SHOW_ALL_ALLOWED. Reopen or new ticket?
Just to make sure i've understood the topic here: you need to change MAX_SHOW_ALL_ALLOWED, but only for a specific model? Otherwise you could just add something like that to, say, the root urlconf: from django.contrib.admin.views import main as admin_views_main admin_views_main.MAX_SHOW_ALL_ALLOWED = 1000 In the original ticket, there's no mention of this possibility, which I believe is a possible solution to (part of) the problem. Sorry for the noise if I missed the point. Mathieu -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Field lookup types and backwards incompatibility
I thought Django already did option 1. If it doesn't, why not? What
are the possible edge cases? Using a date field named "date" as a
foreign key to another model that also contains a "date" field?
On May 10, 1:47 am, Ulrich Petri wrote:
> Currently there are at least 4 open tickets [1-4] that propose the addition
> of new lookup types. Two of them [1,2] are in DDN because of backward
> compatibility concerns.
> Following that (IMHO valid) logic makes it impossible to _ever_ add new
> lookup types to django without breaking backwards compatibility since field
> lookup types and field names share the same namespace.
>
> Interestingly there has been one instance [5] where a lookup type was added
> after the 1.0 release (as far as I could gather from SVN). Why no backward
> comp. concerns were voiced in that case is not clear from the ticket.
>
> Also there is currently no validation preventing field names from clashing
> with the already existing lookup types (date, year, month, day, etc. are
> IMHO "easy targets"). Whether that would be a desirable feature to have is
> also debatable since it would "artificially" limit a developers naming
> choices.
> That using conflicting field names usually causes no problems but blows up
> with a rather confusing error message (e.g. "TypeError: Related Field has
> invalid lookup: [...]") when querying for that field through a relation
> without an explicit lookup isn't helpful either.
>
> To solve this situation I think there are two possibilities:
>
> 1. Make the current implementation "smarter": Don't automatically assume
> that the last filter part is a lookup type but instead check first if there
> is a field of that name.
> 2. Separate the field name and lookup namespaces:
> Either change the separator for lookup types (e.g. to 3 underscores) or
> introduce a completely different way of specifying lookups (e.g.
> Thing.objects.filter(some_field__other_field=lookups.Contains("blah")))
>
> Option one clearly is far less invasive (and possible to implement short
> term) but has the potential of user / developer confusion and maybe some
> hard-to-get-right edge cases.
> Option two is a big hammer and possibly (probably?) not something the core
> devs are willing to change even in the long term?
>
> So what do people think?
>
> Bye Ulrich
>
> [1]http://code.djangoproject.com/ticket/8424
> [2]http://code.djangoproject.com/ticket/9596
> [3]http://code.djangoproject.com/ticket/10911
> [4]http://code.djangoproject.com/ticket/12489
> [5]http://code.djangoproject.com/changeset/9818
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: TemplateResponse and decorator_from_middleware
> These features have the stated purpose of allowing a response to be > altered by middleware or decorators. However, if a decorator causes the > template to be rendered, then such alterations will not happen. > > This is a serious issue, because decorators like these are often applied > on an ad-hoc basis, without thinking that they are going to change > things like the body of the response. > > So, if we need to cache one page, on a site without global caching, the > obvious thing to do is to add the cache_page decorator. Unfortunately, > if you were actually using a template response middleware, you'll almost > certainly have breakage. It is really bad that adding cache_page can > change what would actually be rendered, and this could be extremely hard > to debug. Similarly with the other affected decorators. I just wanted to amend my post to say that when I said that this was a "small race condition" (is it a race condition? maybe that's the wrong term as concurrency doesn't come into play), I hadn't thought this through. Yeah, the usefulness of the TemplateResponse is much reduced when you have to worry about decorators accessing the content of the response. But that should be obvious, right, at least for caching? Certainly if you cache a response before you modify it either the cache will have to be wrong or the modifications have to will fail. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: TemplateResponse and decorator_from_middleware
Hi Luke, I actually faced a problem similar to this when I ported CBV from 1.3 to 1.2, and then tried to use the TemplateResponse with a couple of middleware decorators that I created from some custom middleware classes. If I recall properly, I was also having backwards incompatibility problems with some other middleware classes that I had installed. The solution for me was actually very simple: instead of raising a ContentNotRenderedError on line 110 of django/template/response.py, I modified the code of _get_content() to call self.render(), that way making a TemplateResponse look just like a standard response with a static "content" field. Doing it this way still allows TemplateResponse to be useful, it just requires you to be careful how you order middleware classes so that the template context is updated before request.content is accessed (i.e. at the very front). It's a small race condition, but not inconsistent with the other ordering issues that go along with using middleware. That being said, I don't know if the bug I encountered was exactly the same as what you are describing, I can't quite recall the details, but I just wanted to throw this out there anyway. This may not be a complete or ideal solution, but if it works, it seems like a better option than changing the middleware API--and better than making backwards-incompatible changes to decorator_from_middleware. Regards, Ed Gutierrez -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: TemplateResponse and decorator_from_middleware
On 12/05/11 00:20, Carl Meyer wrote: > Yeah, this is bad. I don't have a lot to add at the moment, except to > also point out #15855 - cache_page as a decorator breaks proper setting > of Vary headers. > > The reason I bring it up here is just to point out another case, > unrelated to TemplateResponse, where we promote the idea that you can > use a decorator as a view-specific equivalent to a middleware, but doing > so breaks the semantics of the original middleware in subtle but > significant ways (because it changes the order things happen in). > > Not sure what that implies, except that maybe decorator_from_middleware > and the pattern it encourages is ultimately at least as problematic as > TemplateResponse... Yeah, I guess I was seeing TemplateResponse as the culprit, on the basis of Last In First Out, but maybe it's decorators we need to be worrying about. I've actually documented a specific instance of #15855 in the CRSF docs And while we're on the subject, another problem with decorators vs. middleware: A stack of decorators can behave differently from the corresponding stack of middleware, due to subtle differences in the ordering of method calls e.g. [m1.process_request, m2.process_request, m1.process_view, m2.process_view] vs [m1.process_request, m1.process_view, m2.process_request, m2.process_view] Regards, Luke -- Parenthetical remarks (however relevant) are unnecessary Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: DecimalField allows float value as 'default'.
On Thu, May 12, 2011 at 3:35 AM, Shawn Milochik wrote: > Someone on django-users just commented that they set a default value on a > DecimalField as a float, and were surprised when they were unable to create > a queryset using a float to find records. > > I searched Trac for the terms 'DecimalField default' and didn't see anywhere > that this was brought up before. > > Should there be a validator added to the DecimalField that checks whether > decimal.Decimal(default) is a valid operation if default isn't NOT_PROVIDED? > Or maybe an override to __init__ in DecimalField that calls super().__init__ > then does this test. > > Currently, it appears that this works because the value of 'default' is > coerced to unicode by Field's get_default(). This results in an invalid > value (float) being treated as valid for a DecimalField. If DecimalField is accepting anything other than a DecimalField (or a string, for historical reasons -- but that's true of any Field) under *any* circumstances (default, new field value, etc), then it should be raising an error. A float can't be reliably converted to a Decimal, because you don't have guaranteed precision. If this hasn't already been reported, then it should be. I have a vague recollection of something about DecimalField defaults coming up in the last year or so (either on Trac or Django-dev), but that could just be a random pre-coffee neuron firing... I'll defer to anyone who has actually done the Trac search :-) Yours Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: TemplateResponse and decorator_from_middleware
On 05/11/2011 05:37 PM, Luke Plant wrote: > The only solution I can see that isn't awful is providing two views - a > default and documented one that has all the right decorators applied, > and one that is obviously 'use at own risk', called something like > 'login_unsafe', for which we document the extra things you need. > > I can see even less room for process_template_response - it just isn't > useful to add a middleware for the sole purpose of messing with the body > of any response, only to find that in many cases you can't mess with > them after all, since the developer had to do something like add caching > to a particular view etc. > > So where does this leave us? I don't know. I did have some bad feelings > about TemplateResponse and the idea of lazy responses, but didn't voice > them at the time because I didn't have anything but a vague feeling of > unease (which is not something you can either defend or argue against), > and I wasn't involved in reviewing that feature much. Yeah, this is bad. I don't have a lot to add at the moment, except to also point out #15855 - cache_page as a decorator breaks proper setting of Vary headers. The reason I bring it up here is just to point out another case, unrelated to TemplateResponse, where we promote the idea that you can use a decorator as a view-specific equivalent to a middleware, but doing so breaks the semantics of the original middleware in subtle but significant ways (because it changes the order things happen in). Not sure what that implies, except that maybe decorator_from_middleware and the pattern it encourages is ultimately at least as problematic as TemplateResponse... Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: RFC: #12417 - Support for signing (including secure cookies)
On 11/05/11 20:20, Jannis Leidel wrote:
> Hi all,
>
> This is in continuation to Simon's previous efforts about adding tools
> for easy signing, including secure cookies ([1], [2]).
>
> Stephan (who is working on #9200 [3] -- improving the wizard in
> contrib.formtools) and me just updated the patch attached to ticket
> #12417 [4] with the recommended changes according to the mailing list
> threads and the Trac ticket:
>
> http://code.djangoproject.com/attachment/ticket/12417/ticket12417-v4.diff
>
> The complete changes (as noted) are:
>
> - Moved from django.utils.signed to django.core.signing
> - Removed the seperator argument to the Signer.sign and Signer.unsign
> methods and moved it to a class attribute
> - Added key prefix ('django.http.cookies') to Signer instantiation
> - Changed key ordering from `"signer" + key + salt` to `salt + "signer" + key`
> to lower the chance for brute force attacks
> - PEP8 and other style changes
> - Use constant_time_compare from django.utils.crypto for timing attack
> proof signature verification
> - Updated and fixed docs
> - Changed setting name from COOKIE_SIGNER_BACKEND to SIGNING_BACKEND
>
> We'd appreciate any further comments before I commit this patch, given
> the formtools wizard being dependent on it for its cookie storage backend.
We already have one way of using hmac with unique keys for each
application - django.utils.crypto.salted_hmac. I looked at the code, and
can't see any reason we couldn't make Signer use that code path, rather
than having two very similar code paths. I see no reason for the new
code to directly use either settings.SECRET_KEY or hmac even once, and
doing so makes our code much harder to audit for security problems -
every place where we use SECRET_KEY or hmac directly is a place we have
to worry about.
Currently we have 4 uses of SECRET_KEY (one of them is in a deprecated
code path), and 1 use of hmac.new.
So I feel quite strongly that we should fix this code to use
salted_hmac. (Or fix salted_hmac if there is some problem with it, but
remembering that there is lots of data that depends on it).
I haven't had time to further review, but thought I'd get that out
straight away.
Regards,
Luke
--
Parenthetical remarks (however relevant) are unnecessary
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Odp: Re: Re: get_or_create can still cause IntegrityError
W dniu poniedziałek, 9 maja 2011, 19:05:17 UTC+2 użytkownik SleepyCal napisał: > > Hi guys, > > I spent literally *months* trying to find the best way to resolve this > situation. (...) > Have you checked my StackOverflow answer I linked in the top post? It *completely* removes the problem for MySQL/InnoDB, on REPEATABLE READ isolation level. If you use Postgres with comparable isolation level then my solution might also work for you. For READ COMMITED level the problem shouldn't occur anyway. Tomasz -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: TemplateResponse and decorator_from_middleware
OK, I've thought about this a bit more, and I think we have some nasty problems. First, existing decorators: 1) It looks like the cache_page decorator will actually work with TemplateResponse, but only because the cache middleware special-cases responses with a 'render' method. This is cheating really - if we had to patch this middleware to get it to handle TemplateResponse, then there will be many other 3rd party pieces of middleware that will need similar fixes, yet we gave no-one any warning of this in the 1.3 release of this fairly major backwards incompatibility. 2) crsf_protect, and almost certainly conditional_page and gzip_page, are broken for TemplateResponse objects (to a greater or lesser degree), due to decorator_from_middleware not rendering TemplateResponse objects before passing them to the process_response method. So, we need to fix decorator_from_middleware. I think that is unavoidable. Once we do that, and even before we do it in the case of cache_page, we have to face the fact that these decorators, and possibly others like them, cause TemplateResponse objects to be rendered. This means that the usefulness of TemplateResponse and 'template response middleware' are seriously reduced: These features have the stated purpose of allowing a response to be altered by middleware or decorators. However, if a decorator causes the template to be rendered, then such alterations will not happen. This is a serious issue, because decorators like these are often applied on an ad-hoc basis, without thinking that they are going to change things like the body of the response. So, if we need to cache one page, on a site without global caching, the obvious thing to do is to add the cache_page decorator. Unfortunately, if you were actually using a template response middleware, you'll almost certainly have breakage. It is really bad that adding cache_page can change what would actually be rendered, and this could be extremely hard to debug. Similarly with the other affected decorators. I can see 2 ways that TemplateResponses are still useful: 1) if you have 'sub views', which are private and are not going to be decorated with any of these things, and want to return responses to the main view for finalising, and you only put decorators on the main view. 2) if you provide re-usable views in a re-usable app, which have deliberately have no decorators applied, but come with instructions about the decorators that have to be applied to them. However, the 2nd of these could make things pretty icky. A case in point is django.contrib.auth.views.login. Once we fix csrf_protect, the TemplateResponse returned will be immediately baked, and so it is pointless using it in the first place. If we don't put csrf_protect on it, we've got a security problem - we agreed that with re-usable apps, we don't want to rely on people using CsrfViewMiddleware, but we also don't want to rely on people reading instructions like "make sure you apply csrf_protect to this view". The only solution I can see that isn't awful is providing two views - a default and documented one that has all the right decorators applied, and one that is obviously 'use at own risk', called something like 'login_unsafe', for which we document the extra things you need. I can see even less room for process_template_response - it just isn't useful to add a middleware for the sole purpose of messing with the body of any response, only to find that in many cases you can't mess with them after all, since the developer had to do something like add caching to a particular view etc. So where does this leave us? I don't know. I did have some bad feelings about TemplateResponse and the idea of lazy responses, but didn't voice them at the time because I didn't have anything but a vague feeling of unease (which is not something you can either defend or argue against), and I wasn't involved in reviewing that feature much. Luke -- Parenthetical remarks (however relevant) are unnecessary Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
DecimalField allows float value as 'default'.
Someone on django-users just commented that they set a default value on a DecimalField as a float, and were surprised when they were unable to create a queryset using a float to find records. I searched Trac for the terms 'DecimalField default' and didn't see anywhere that this was brought up before. Should there be a validator added to the DecimalField that checks whether decimal.Decimal(default) is a valid operation if default isn't NOT_PROVIDED? Or maybe an override to __init__ in DecimalField that calls super().__init__ then does this test. Currently, it appears that this works because the value of 'default' is coerced to unicode by Field's get_default(). This results in an invalid value (float) being treated as valid for a DecimalField. Shawn -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Continued work on a django.contrib.formtools.wizard replacement
On 11.05.2011, at 20:35, David Durham wrote: > On Mon, Apr 25, 2011 at 11:09 AM, Stephan Jäkel wrote: >> Hi everybody, >> >> I want to continue the discussion on the replacement of >> django.contrib.formtools.wizard (previous discussions can be found here: >> http://bit.ly/eI5ZT5 and http://bit.ly/gVTRtr). > > > I keep seeing some maintenance type of activities taking place against > the ticket I created: > > http://code.djangoproject.com/ticket/9200 > > Probably someone should just close this ticket? Yeah, we've just updated the attached patch with the recent changed made in the depending ticket #12417, so closing isn't a good idea. http://code.djangoproject.com/attachment/ticket/9200/ticket9200-1.diff Also see the other thread about signing [1]. Please don't hesitate to take a look at the changes, even if the docs are currently sparse, we intend to improve them in the next couple of days. Of course patches are more than welcome. Stephan and Jannis 1: http://groups.google.com/group/django-developers/browse_thread/thread/ef65c82c5252ac5d -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
RFC: #12417 - Support for signing (including secure cookies)
Hi all,
This is in continuation to Simon's previous efforts about adding tools
for easy signing, including secure cookies ([1], [2]).
Stephan (who is working on #9200 [3] -- improving the wizard in
contrib.formtools) and me just updated the patch attached to ticket
#12417 [4] with the recommended changes according to the mailing list
threads and the Trac ticket:
http://code.djangoproject.com/attachment/ticket/12417/ticket12417-v4.diff
The complete changes (as noted) are:
- Moved from django.utils.signed to django.core.signing
- Removed the seperator argument to the Signer.sign and Signer.unsign
methods and moved it to a class attribute
- Added key prefix ('django.http.cookies') to Signer instantiation
- Changed key ordering from `"signer" + key + salt` to `salt + "signer" + key`
to lower the chance for brute force attacks
- PEP8 and other style changes
- Use constant_time_compare from django.utils.crypto for timing attack
proof signature verification
- Updated and fixed docs
- Changed setting name from COOKIE_SIGNER_BACKEND to SIGNING_BACKEND
We'd appreciate any further comments before I commit this patch, given
the formtools wizard being dependent on it for its cookie storage backend.
As always don't hesitate to ask if there are any questions.
Best,
Stephan and Jannis
1:
http://groups.google.com/group/django-developers/browse_thread/thread/d9d635afb6d1820f/
2:
http://groups.google.com/group/django-developers/browse_thread/thread/297e8b22006f7f3a/
3: http://code.djangoproject.com/ticket/9200
4: http://code.djangoproject.com/ticket/12417
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Continued work on a django.contrib.formtools.wizard replacement
On Mon, Apr 25, 2011 at 11:09 AM, Stephan Jäkel wrote: > Hi everybody, > > I want to continue the discussion on the replacement of > django.contrib.formtools.wizard (previous discussions can be found here: > http://bit.ly/eI5ZT5 and http://bit.ly/gVTRtr). I keep seeing some maintenance type of activities taking place against the ticket I created: http://code.djangoproject.com/ticket/9200 Probably someone should just close this ticket? -Dave -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
old patches, 15064, 15595
http://code.djangoproject.com/ticket/15064 http://code.djangoproject.com/ticket/15595 Hi. Just wondering if someone could take a look at these. It's been two weeks since the last activity, and already one of them had a merge conflict with trunk, so I just updated it. If there's a problem with either one please let me know. Thanks, Shawn -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: NoSQL support
> You do make a good point. It's not just that NoSQL systems lack > features (transactions, schema, relations) that are common to SQL- > based systems Actually most graph databases (such as neo4j) which are all considered NoSQL, have all those features you just mentioned (ACID, relations, schemas, etc.). At some point down the line I'd like to maybe use PostgresSQL, MongoDB and neo4j with the ORM. Maybe that's to much, maybe not. Maybe it's a bad idea, maybe not. We shall see ... -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Field lookup types and backwards incompatibility
On 05/11/2011 03:17 AM, Chris Beaven wrote: 3. Change lookups to be uppercase (start the process of deprecating the current lowercase ones) uagh, .filter(foo_CONTAINS=bar)? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: NoSQL support
On Tue, May 10, 2011 at 11:29 PM, Patryk Zawadzki wrote: > On Tue, May 10, 2011 at 9:40 PM, legutierr wrote: >> Maybe it is inevitable that this kind of debate will crop up in any >> discussion of django-nonrel or NoSQL, but I very much hope that the >> philosophical debate does not detract from this fact: that django- >> nonrel has demonstrated in very real terms that the actual changes >> needed for Django's ORM to interface with a diverse set of non- >> relational systems, are, in the general scheme of things, relatively >> minor. Because they are localized and relatively minor, if those >> changes do not have a negative impact on the usability and stability >> of the ORM, and if they do not introduce noticeable backwards >> incompatibility, that small set of changes should, in my opinion, be >> considered for acceptance into Django. > > Please don't get me wrong. I have worked with RDBMS for more than a > decade but I alse use django-nonrel with MongoDB on a daily basis. I > also think that the approach django-mongokit takes is much more > natural for NoSQL data than just reusing the ORM. The ORM has no way > to express complex structures and if such support is added, you will > always have to choose which subset to use. Are EmbeddedModelField and DictField not enough to express complex structures? Django-nonrel currently only doesn't allow to run complex queries on those fields, but that can be added. Bye, Waldemar -- Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source: http://www.allbuttonspressed.com/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
