Re: Model validation

I'm personally waiting for Malcolm to create the SVN branch with his updates for continuing model validation work. However, as 1.1 freeze is drawing near, he probably has a lot more to deal with. So, looks that the work will be suspended until Malcolm has a free time slot for creating the branch.

Serving static files with handler-specific sendfile()

http://code.djangoproject.com/ticket/2131 tracks adding support for efficiently serving files from within Django via handler-specific wrapper for sendfile(). A new response class, HttpResponseSendFile is added for that purpose. In my humble opinion it should visibly and loudly break if the handl

Re: Serving static files with handler-specific sendfile()

A Ruby developer has a blog post on that: http://john.guen.in/svn/plugins/x_send_file/lib/ . No compromises there, :render => { :nothing => true } (don't return anything in the content). --~--~-~--~~~---~--~~ You received this message because you are subscribed

Re: Call for ideas: Admin Improvements

Add and remove instances to/from formsets with a button click is much needed instead of the current delete checkbox and `extra` handling (both for formsets in general and for admin formsets in particular). There is a snippet (that I've not tried) at http://www.djangosnippets.org/snippets/1389/ .

Re: Call for ideas: Admin Improvements

On Mar 31, 2:41 pm, Russell Keith-Magee wrote: > Correct. Django has very deliberately made a decision to avoid > blessing any single Javascript toolkit. It is unlikely that this will > change simply because a GSoC applicant has proposed it. Proposals that > hinge on the use of JQuery (or any oth

Re: Call for ideas: Admin Improvements

allowed or not. On Mar 31, 4:30 pm, Russell Keith-Magee wrote: > On Tue, Mar 31, 2009 at 9:02 PM, mrts wrote: > > > On Mar 31, 2:41 pm, Russell Keith-Magee > > wrote: > >> Correct. Django has very deliberately made a decision to avoid > >> blessing any singl

contrib.admin is slow with large, complex datasets

I've submitted #10697 with the following problem statement. Please comment. --- Suppose I have a complex admin page that, given the following models: class A(models.Model): name = models.CharField(...) # 10 more fields, some of them e.g. TextFields() def __unicode__(self):

Re: Follow-up to "contrib.admin is slow with large, complex datasets"

Omission: the models and admin used in experiments have changed a bit from the original post: from django.db import models class Base(models.Model): name = models.CharField(max_length=10) lots_of_text = models.TextField() class Meta: abstract = True def __unicode__(self

Re: Follow-up to "contrib.admin is slow with large, complex datasets"

First, let me thank Malcolm for promptly fixing #10710. Unfortunately #10733 is still barring the use of only() and select_related() properly. Given the models and admin defined above and the requirements that * admin changelist view should perform only a single query, * that should pull in onl

Re: Follow-up to "contrib.admin is slow with large, complex datasets"

On Apr 6, 2:45 am, Jacob Kaplan-Moss wrote: > Can you please stop? We all get that you think these tickets are > important. They're on the milestone for 1.1, so they'll be fixed. > Nagging us here doesn't help get your tickets pushed to the front of > the queue. I'm baffled. From which parts of

Re: Why does get_profile exist?

On Apr 15, 11:04 am, David Cramer wrote: > I was never a fan of the profile model as it stands. It's not very > practical in every situation I've ever been in. Being that 1.0 was > supposed to be backwards compatible, and this is a public API I think > it needs to stay. > > I'd love to see a wa

Re: Search for the ORM and Haystack

On Apr 19, 3:48 am, Ben Firshman wrote: > This includes support for PostgreSQL in addition to MySQL,  searching   > across multiple fields, automatic index creation, relevance, admin   > full text search and a simple generic search view. A brief example of   > the API: > > class Article(models.Mo

Re: Search for the ORM and Haystack

On Apr 24, 3:49 am, Joseph Kocherhans wrote: > On Thu, Apr 23, 2009 at 6:50 PM, Ben Firshman wrote: > > > On 19 Apr 2009, at 11:42, mrts wrote: > > > > The feature is much needed, thanks for dealing with this! > > > > However, as for the API,

GSOC process

To get more visibility and community input for the scope of GSOC projects, let me propose the following workflow. 1. A keyword is chosen for each project --- * model validation: model-validation (already existing) * multiple database support: multi-db * admin

Re: GSOC process

As an example I've tagged a couple of tickets with gsoc09-admin- refactor: http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&status=closed&keywords=~gsoc09-admin-refactor&order=priority --~--~-~--~~~---~--~~ You received this message be

Re: limiting admin inlines by limit_choices_to

Looks like a general refactoring of admin queryset handling is needed. That would also cater for this use case (InlineAdmin objects supporting queryset() would solve your case). See http://code.djangoproject.com/ticket/11019 and http://code.djangoproject.com/ticket/10761 . On May 22, 10:24 am, E

Re: ImageField performance

The 20+ lines of http://code.djangoproject.com/browser/django/trunk/django/core/files/images.py#L31 are needed to support remote storage backends. However, quite a few of us are *not* using remote storage backends. def get_image_dimensions(file_or_path): from PIL import Image # fallback

Re: Deleting an object deletes objects with nullable foreignkeys pointing at it

On Jul 27, 10:34 pm, Stephen Sundell wrote: > If I delete an edition (edition.delete()), it deletes all the emails > associated with it.  I thought it was just supposed to set the foreign > key to null.  Am I wrong in my thinking or doing something incorrect? http://code.djangoproject.com/ticket

Show related object popup when a selected option is clicked in ManyToMany autocomplete field

Hello! Currently admin ManyToMany autocomplete fields don't allow editing selections like ForeignKey fields do. I would like to suggest adding adding editing by showing the related object popup when a selected option is clicked in a ManyToMany autocomplete field. Alternatively, the unicode penci

Exposing custom views in admin index page

Hello! Django ModelAdmin class has a nice way to create custom admin views with get_urls(). What is missing however is a way to expose them in the admin index page. Frank Wiles created the (now abandoned) django-admin-views package [1] as a workaround and there are many questions regarding thi

Re: Exposing custom views in admin index page

...) > > (I appreciate that doesn't address the "should we have this in core?" > question.) > > On Wednesday, 6 March 2019 12:40:06 UTC+1, mrts wrote: >> >> Hello! >> >> Django ModelAdmin class has a nice way to create custom admin views with >

#7028 Pledge not to deprecate raw_id_fields

Tim Graham writes in https://code.djangoproject.com/ticket/7028: *I think it doesn't make sense to add this enhancement while also adding a new autocomplete widget (#14370 ). After the autocomplete widget is added, we might deprecate raw_id_fields i

Re: TextIndexingAbstractionLayer and FullHistory branches for GSoC

In my humble opinion a search abrastraction app bundled in django.contrib is a really high priority and has suitable scope for a SoC project. Qouting James http://www.djangosnippets.org/about/faq/: "Why isn't there a search system? Because no-one's yet written a good generic search system for Dja

Re: TextIndexingAbstractionLayer and FullHistory branches for GSoC

Though search is of primary importance, object history is obviously very important as well -- both auditing (Audit Log pattern) and rolling back/comparing changes (Temporal Object pattern) are very common use cases (see Martin Fowler's treatment of these and some other patterns for things that cha

Re: django.contrib.sessions problems

> After reading through these, I think most of these can be satisfied > with the proper session backend. Why not write a "secure" session > backend? (You would presumably also need to require signed cookies for > the session.) I would be interested to see what it would look like. I think a genera

django.contrib.sessions problems

SessionStore is missing a clear() or invalidate() method that will destroy the session. Is this intentional? If so, why? Cleaning a session is such a common requirement for session frameworks. Looking through tickets, I found the following relevant to general session logic (in no particular order

Threading improvements

I started the following proposal: http://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threading Quoting: "According to tickets #5632, #6950 and discussions http://groups.google.com/group/django-users/browse_frm/thread/a7d42475b66530bd, http://groups.google.com/group/django-developers/b

Re: django.contrib.sessions problems

I started http://code.djangoproject.com/wiki/DjangoSpecifications/Contrib/Sessions to properly sort this out. Please edit. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this gr

Re: django.contrib.sessions problems

On Apr 4, 4:00 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > No, please post here. I know you want there to be a formal spec > process, but there isn't. Right now the way we decide things is by > posting them here, and you need to do the same. I entirely accept that. The proposal pages a

Re: "Proposals" on the wiki

contributions. And all of it is already happening, Malcolm has created an excellent overview of qs-refactor in wiki and the same with nf-admin. On Apr 4, 6:34 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > On Fri, Apr 4, 2008 at 8:37 AM, mrts <[EMAIL PROTECTED]> wrote

Re: What is considered the best platform to run django on using Linode

Please ask this question on django-users. This group is for discussions on Django internals only. [EMAIL PROTECTED] wrote: > I was thinking of using Lighttp on one of the 760 servers. Is there a "best > OS" to make setup go smoothly. > > Any tips or references are very welcome. I need to develop

Re: Threading improvements

This post is *horribly* long. I tried to make it as structured and accessible as I possibly could. Holding myself back to say the forbidden words -- a ikiw egap dluow ekam siht erom elbadaer *chuckle*. Concurrency at DB level === Background -- The general threading c

Re: django.contrib.sessions problems

> Why not write a "secure" session backend? (You would presumably > also need to require signed cookies for the session.) The cookies are already signed. Session data + settings.SECRET_KEY is md5-digested and tampering raises an exception. So in that sense the sessions are already secure. Note th

Re: django.contrib.sessions problems

> Session objects is the right place to store all session-related data. > It's a many-to-one relation to each user. If you want something that's > one-to-one with a user, that isn't session data and is easy to implement > via your own model, but I'm not sure it's common enough to have a common > A

Re: django.contrib.sessions problems

> Realise that I am in agreement with you that logout (and possibly login, > I haven't worked through the implications there) should be changed to > clear the session by default. There's no strong reason not to do that, > since the session is over when logout is called (I'll raise that > separatel

Re: django.contrib.sessions problems

> def show_foo(request): > request.session['foo'] = 'bar' > request.session.delete(request.session._session_key) > return HttpResponse(request.session['foo']) > > In [1]: from django.contrib.sessions.backends.db import SessionStore > In [2]: s = > SessionStore(session_key='61a271f29a67

Re: django.contrib.sessions problems

On Apr 8, 12:53 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > Agreed, but as previously described, there should be a way to override > > the default behaviour and retain session data if needed. > > No, I don't see any need for this at all. Once you've logged out, the > session is over. S

Allow Form._clean() to specify the invalid field

Quoting problem statement from #6652: "Currently the Form.clean() method has no way to specify which field is invalid, but it's the only place where validation involving many fields can be accomplished. Taking your example in the documentation: This is where you might put in things to check that

Re: new-forms admin shouldn't throw error when a model is registered twice #6776

As double imports should be considered harmful, I'd rather see a better warning there, in the lines of ""The model Foo is already registered. This can be caused by a double import, see docs/bar.txt for ways to avoid it." (Double imports are triggered by mixing relative and absolute imports, e.g. i

SecureForm in newforms

If one wants to protect all POSTed data against CSRF, one should use CSRFMiddleware. However, a common use case is to protect only some POSTed forms and let other POST data through (e.g. Ajax POSTs, OpenID consumers etc -- CsrfMiddleware will not let them through without the token). Currently, a

Re: SecureForm in newforms

> Middleware is easy to set and forget.  Is there a reason not to make > SecureForm the default, and InsecureForm for people using Ajax?  ;-) Doesn't fit my workflow. In my case some POSTs are handled internally by other libraries (think OpenID). --~--~-~--~~~---~--~--

Re: Maybe DEBUG=True should only record the last N SQL queries?

I'd second Simon's proposal. People often develop their projects on production servers and need to have debug on. Having to manually flush the query log disrupts their normal workflow. I'd suggest being kind to the users and not work against their intuition by default. As Simon proposed, whoever n

Re: {{ something or something_else }}

Although this is really off-topic in this list, there's also http://www.djangoproject.com/documentation/templates/#firstof {% firstof foo bar baz %} that has the added benefit of outputting nothing if all of foo bar baz evaluate to False. On Apr 25, 6:35 pm, "Wolfram Kriesing" <[EMAIL PROTECTED

Re: API question for model saving

Looks like enums would be the most natural solution. As Python doesn't have enums, class attributes should be used (module level globals would clutter the namespace). Adding to Malcolm's initial proposal: # django/db/models.py class CreateStrategy: MUST_CREATE = True MUST_NOT_CREATE = Fals

Re: GSOC: More backends for djangosearch

Good luck with the project! Has something been decided on using db backend full text search facilities as a convenient start? The point is that indexers are overkill for smaller projects and they may not be available in constrained environments (e.g. shared hosting). In this case it should be ea

Re: GSOC: More backends for djangosearch

> It currently works something like this: > > from django.db import models > from djangosearch import ModelIndex > > class Article(models.Model): >     title = models.CharField(max_length=255) >     date = models.DateField() > >     index = ModelIndex(fields=['title', 'date']) > >     def __unicod

Re: GSOC: More backends for djangosearch

Excellent. Looking forward for the finished project! On May 5, 4:50 pm, Ben Firshman <[EMAIL PROTECTED]> wrote: > > For everything: > > results = djangosearch.search("query") > > or more specific: > > results = djangosearch.search("query", models=[Foo, Bar]) --~--~-~--~~~

<    1   2