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

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 >

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

#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: Threading review wiki page removal

On Apr 7, 6:21 pm, Russell Keith-Magee wrote: > James spoke with me about this decision at the time, and I completely > agree with and endorse his actions. So be it then. > While it is true that wikis contain all sorts of information, often > unofficial, the naming of the wiki pages in question

Threading review wiki page removal

James has replaced the content of http://code.djangoproject.com/wiki/DjangoSpecifications/Core/Threading with the following disclaimer: "This page and several others were created by a wiki user who was not and is not a member of the Django core team. Previous contents of this and other similar p

Re: Deprecating cmemcache, adding pylibmc

On Mar 1, 5:27 pm, Jacob Kaplan-Moss wrote: > Also, a step 2.5, if you'd like, would be to write a tiny app on pypi > that enabled the use of pylibmc via an external cache backend. We > could point to it in the deprecation notes when we explain why > cmemcache is being deprecated. See http://gist

Re: Status of branch soc2009/http-wsgi-improvements? (and ticket 2131)

On Feb 10, 5:24 pm, Tom Evans wrote: > On Wed, Feb 10, 2010 at 3:09 PM, Jari Pennanen > wrote: > > Hi! > > > I was wondering what is the status of branch branches/soc2009/http- > > wsgi-improvements > > (http://github.com/django/django/tree/soc2009/http-wsgi-improvements > > )? I'm personally

Re: What The Enterprise wants from Django

On Jan 20, 5:59 am, David Cramer wrote: > The first three have been huges ones with us. We're just now running > into the settings issue, but would love to see what people can come up > with for solutions (we dont have a good one). The override_settings() idea that Eric Florenzano describes at ht

Re: Finalizing model-validation: ComplexValidator

Malcolm had some good comments when all of this was discussed previously: http://groups.google.com/group/django-developers/browse_thread/thread/436307e426844ae0/f2fa0647b97569ad He also seemed to have further ideas and code, perhaps he can be pinged for sharing them. Best, MS -- You received t

Re: Sprint issue tracking / triaging

> On Tue, Dec 8, 2009 at 12:35 PM, Jeremy Dunck wrote: > > Sorry to hear that.  The document you linked is a start, but I'm a bit > > concerned by this goal: > >  "to keep the main integration branch as stable as the official trunk > > so that it can be used in actual deployments" > > > My concern

Re: Sprint issue tracking / triaging

On Dec 8, 5:32 am, Russell Keith-Magee wrote: > On Tue, Dec 8, 2009 at 11:11 AM, Tobias McNulty > wrote: > > On Mon, Dec 7, 2009 at 6:31 PM, Russell Keith-Magee > > wrote: > >> I was thinking more of having one person at the sprint to take the > >> role of integrator - that is, the patches stil

Re: Regularly-scheduled Django sprints, first December 11 - 13

On Nov 11, 1:57 pm, Russell Keith-Magee wrote: > Also - I know you're very enthused about Git and GitHub, but Django > uses SVN as the canonical store for trunk and branches, and this isn't > likely to change in the near future. Thank you, but no, I'm not enthused about git and GitHub per se :)

Re: Regularly-scheduled Django sprints, first December 11 - 13

Great news! Have you discussed the workflow yet? I.e. will a DVCS be involved, and if yes, will there be a central repo for coordinating the effort? A special repo on Github would otherwise be perfect, but as mentioned before, we have a problem with re-forking: http://support.github.com/discussio

Re: Inline Formsets Again

On Oct 28, 9:43 am, John Debs wrote: > I've written a creaky hack to work around the issue in my own projects > but after seeing this thread I'm going to take a shot at implementing > FormSetField (or something like it) myself. If anyone has any code - > or more arguments for or against that have

Re: Bug in django\template\__init__.py ??

On Oct 29, 4:50 pm, Russell Keith-Magee wrote: > Django's dependence on DJANGO_SETTINGS_MODULE is an oft-lamented > problem. Suggestions on how to address this constraint are most > welcome. With an explicit main (i.e. a single explicit entry point to code). Would also fix the "where can I initi

Re: The this-needs-to-be-in-django angst

> Another benefit of a merge-queue branch is testing and verifying that > multiple patches play well together before actually hitting trunk. > For multiple big branches this is even more important. Currently blocking on http://support.github.com/discussions/feature-requests/560-two-forks-of-a-sin

Re: The this-needs-to-be-in-django angst

On Oct 22, 3:36 am, Russell Keith-Magee wrote: > On the other hand, saying "I am going to" is extraordinarily helpful. > Saying "I already have" is even better. You don't need the core's > blessing to do anything. Yes, I wholeheartedly agree and that was the point of my initial message. > Allow

Re: The this-needs-to-be-in-django angst

On Oct 20, 7:19 pm, Jacob Kaplan-Moss wrote: > What's frustrating, though, is hearing that you have a > problem with our workflow without any concrete suggestions > to improve it or offers of assistance. There's a general > theme underlying most of this "angst" (as you call it): > the tone implie

Re: The this-needs-to-be-in-django angst

Jacob, I'm afraid you totally misunderstood me. My message was intended to encourage people to scratch their own itches more now that it's so much easier -- and, of course, give back -- instead of grumbling on the mailing list. I fail to see how can "so it's time to put the grudges behind and hap

Re: The this-needs-to-be-in-django angst

(Inspired by Yuri Baburov's criticism and RKM's response.) --~--~-~--~~~---~--~~ 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 unsubscr

The this-needs-to-be-in-django angst

Let me suggest that there are many who have at times felt frustrated how contributions or suggestions are managed in Django. Some of them seem to have walked away or just don't participate in discussions any longer. The same applies to several other large open source projects, the Linux kernel and

Re: Branchy Django developement on GitHub

On Oct 5, 7:08 pm, mrts wrote: > There'shttp://code.djangoproject.com/wiki/CollaborateOnGithub > I will update that page with these instructions, Done. Any comments and amendments should probably go to the wiki page now. Best, MS --~--~-~--~~~---~-

Re: Branchy Django developement on GitHub

There's http://code.djangoproject.com/wiki/CollaborateOnGithub that I wrote some time ago, but it doesn't give guidelines for branchy development. I will update that page with these instructions, but it would be excellent if others who have collaborated more intensively via GitHub could amend the

Branchy Django developement on GitHub

Many core developers and the GSOC folks use GitHub for Django development, so I hope discussing the best practices is appropriate for django-dev. Let me outline the desired workflow, please amend and correct as you see fit as there are probably errors or omissions. I expect various useful pattern

Re: Model.objects.raw() (#11863)

On Oct 2, 7:35 pm, mrts wrote: > But let me stop right here. Contradicting myself, I've pursued this further and implemented raw_override() for order_by in [1] as a proof of concept. See [2] for what's different and tests [3] for usage. I'd say that for order_by, the implem

Re: Model.objects.raw() (#11863)

On Oct 2, 5:42 pm, "Sean O'Connor" wrote: > To be honest this seems like something which would be a lot of work with > relatively little gain.  For this to work raw() would need to change from a > relatively simple bit of code which doesn't need to touch all of the complex > query code in the ORM

Re: Model.objects.raw() (#11863)

Wishful thinking follows. It would be awesome if one could mix ordinary QuerySet methods with raw() (or, rather, raw_extra(), see below for that). Assuming the following models: class Foo(models.Model): name = models.CharField(max_length=255) class FooDates(models.Model): foo = models.

Inline formsets

At HTML level, a form is a set of fields that gets submitted when a the form submit button is pressed. However, this is not the case with model forms and inline formsets (e.g. an admin page with inlines) -- inline formsets are disparate from the model form. This creates at least two problems: 1)

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

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: 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: 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

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: 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,

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: 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: 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: 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"

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

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: 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

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

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: 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

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: 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.

Milestones and roadmap cleanup - thanks!

Jacob, thanks for the great work on Trac cleanup! This makes the devs intentions and goals so much more transparent. I especially like that we have a somewhat official ticket-set-based roadmap now (http:// code.djangoproject.com/roadmap ) instead of the manual one (http:// code.djangoproject.com/

Re: Model-validation: call for discussions

On Feb 19, 12:49 am, Malcolm Tredinnick wrote: > On Wed, 2009-02-18 at 04:28 -0800, mrts wrote: > > The old Field.default_error_messages dict and corresponding > > logic is no longer required (and removed in my branch) as default > > error messages live in core/validators n

Re: Model-validation: call for discussions

On Feb 18, 8:03 pm, Honza Král wrote: > Hi, > see inline text. > > On Wed, Feb 18, 2009 at 1:28 PM, mrts wrote: > > > The last unsolved model-validation design issue is the error message > > protocol (my work on fields is waiting on it). Let me present the > &g

Re: Model-validation: call for discussions

On Feb 18, 2:28 pm, mrts wrote: >    def validate(self, value, all_values={}, form_instance=None): That should have been def validate(self, value, all_values={}): --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Gro

Re: Model-validation: call for discussions

The last unsolved model-validation design issue is the error message protocol (my work on fields is waiting on it). Let me present the approach that looks sane to me. The old Field.default_error_messages dict and corresponding logic is no longer required (and removed in my branch) as default erro

App settings

Whenever the app objects discussion is resuscitated, the following by yours truly may be of relevance: http://github.com/mrts/plugit/tree/master As of now, settings handling is present. The SettingsUpdater class in plugit/settingshandler.py provides a high-level API for updating configuration

Re: Model-validation: call for discussions

After several discussions with Honza, we are still on somewhat different positions what the validator function signature should be and how core validators should access the fields of a form or a model instance. In core validators, no special case handling of forms and models is needed even in mul

Re: Model-validation: call for discussions

On Jan 23, 4:38 pm, Marty Alchin wrote: > I haven't been following everything, but I do have a couple comments > to make here. Thanks, interesting points. The get_value approach looks simpler though, so unless you or anybody else disagrees I'll implement this. --~--~-~--~~---

Re: Model-validation: call for discussions

After discussing with Honza, we agreed that the dichotomy between forms and models that was present before will remain, i.e. instance will always be a model instance if given and all_values will always be form.cleaned_data. Honza's rationale was that it's common to have properties in models and t

Re: Model-validation: call for discussions

As the uniform all values approach has created a bit of confusion, let me present a larger example: Validators in core.validators should not be concerned with either model or form internals if possible. This is currently straightforward to achieve by passing all values always as a dict via form.c

Re: Model-validation: call for discussions

On Jan 23, 3:40 am, Malcolm Tredinnick wrote: > On Thu, 2009-01-22 at 17:27 -0800, mrts wrote: > > [] > > >  A > > side note: the `instance` attribute is not used in validator functions > > and I can't see a clear use case for it, so it looks like it c

Re: Model-validation: call for discussions

On Jan 19, 11:23 pm, mrts wrote: > The directory-based approach is best, I'll go with it -- but it's yet > uncertain > when as I have to handle pressing matters at work during daytime. I've implemented some fundamental changes that need review. The commit is at http

Re: Model-validation: call for discussions

out converters from things that work with standard types. But > definitely try to keep them close together in the source, rather than > putting them in django.utils, which can sometimes be a dumping ground > for stuff that better belongs elsewhere. As seen in the commit, http://github.com/m

Re: Model-validation: call for discussions

odel fields' to_python to a separate django.utils.typeconverters library (see http://github.com/mrts/honza-django/commit/a8239b063591acc367add0a01785181a91a37971 for the first steps in that direction) and using both django.core.validators and django.utils.typeconverters throughout model and form fields. I

Model-validation: call for discussions

There are several problems in model validation as of now. As pouring them out here would create a too long, ill-formatted post, I created a separate page for it at http://wiki.github.com/mrts/honza-django/form-and-model-validation This is just "design gruntwork", a basic text body ana

Overview of the "GitHub process"

Feeling that an overview of the "GitHub process" would help people to get more easily involved, I created http://code.djangoproject.com/wiki/CollaborateOnGithub . Opinions, criticisms and edits most welcome. --~--~-~--~~~---~--~~ You received this message because

Re: Testing speedup checked in

Great thanks and praises to everybody involved! Getting down from 1346 to 204 seconds is such a relief... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email t

Re: Distributed workflow and the woes of slow testsuite

On Jan 12, 3:45 pm, "Jacob Kaplan-Moss" wrote: > On Mon, Jan 12, 2009 at 6:53 AM, mrts wrote: > > What if we try to be nice to ourselves and get #8138 and something in > > the lines ofhttp://oebfare.com/blog/2008/mar/25/faster-django-test-suite/ > > into trun

Distributed workflow and the woes of slow testsuite

A proper "agile" workflow for distributed collaboration on a largeish chunk of functionality should be as follows: Feature developer: * implement tests for the features to be added * commit locally * implement the features * commit locally * run the test suite iteratively, fixing whatever the tes

Re: Some tickets that should perhaps get looked at before 1.1

On Jan 7, 9:59 pm, "Alex Gaynor" wrote: > 1.1 is not 8 days away, the 1.1 major feature freeze, this means items that > are new features on the 1.1 features list. /me puts on a brown paper bag. Right, feature freeze and bug fixing are different things. Can we perhaps agree on a set time when pe

Re: Some tickets that should perhaps get looked at before 1.1

upon him/herself OR someone opposes this). I've created a fork of the unofficial git mirror for that purpose at http://github.com/mrts/django/tree/master . Everybody is most welcome to contribute. By semi-champion I mean that I'll contribute as much as I can beside daily job tasks by di

Re: Ticket 8764 (Mixing args and **kwargs in reverse() function)

On Jan 7, 3:43 am, Malcolm Tredinnick wrote: > On Tue, 2009-01-06 at 15:38 -0800, Killarny wrote: > > There are many instances where, in a complicated implementation of > > views, one might want to have a combination of required args and > > optional kwargs, and the inability to mix them introduc

Some tickets that should perhaps get looked at before 1.1

As the list seems to be resuming from holiday hibernation, I risk causing another "don't you dare to push us" flame-bombing :) by proposing that the following get looked at before 1.1: * `__import__(mod, {}, {}, [''])` causes double import of modules [1] After discussions on python-dev, an idiom

Re: Default manager

See also http://code.djangoproject.com/ticket/9676 On Dec 15, 12:51 pm, "Alex Rades" wrote: > Hi, > my understanding about custom managers is that if you want to define a > custom manager, you also HAVE to remember to define the "objects" > manager first, otherwise some parts of django (eg. admi

Making Django 1.0 work well under Google App Engine

On Aug 11, 9:11 pm, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I'd write more but I'll first wait for responses, file some tickets, > and think about what else Django could do to improve its cooperation > with App Engine... because Django is App Engine's favorite framework! Shouldn't easier in

Re: Dropping Python 2.3 compatibility for Django 1.1

On Nov 26, 3:20 am, Julien Phalip <[EMAIL PROTECTED]> wrote: > On Nov 26, 11:43 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> > wrote: > > > > On Wed, Nov 26, 2008 at 2:08 AM, Jacob Kaplan-Moss > > > <[EMAIL PROTECTED]> wrote: > > > > Hi folks -- > > > > I'd like to officially drop Python 2.3 supp

Re: Explicit default managers?

http://code.djangoproject.com/ticket/9676 created to track this. --~--~-~--~~~---~--~~ 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 un

Explicit default managers?

Currently, "the first manager declared is the default manager". However, given the following hierarchy: --- class PublishedObjectManager(models.Manager): def get_query_set(self): return super(PublishedObjectManager, self).get_query_set()\ .filter(is_published=True) c

Re: Multi-Threaded Dev Server

On Nov 17, 6:54 pm, Ludvig Ericson <[EMAIL PROTECTED]> wrote: > On Nov 16, 2008, at 07:26, Chris wrote: > > > 3. Fear of multi-threading bugs shouldn't be a reason to avoid multi- > > threading, especially when it could be very useful. We don't even know > > if there are multi-threading bugs. And

Re: 1.0.1 release blockers?

On Nov 5, 2:31 pm, mrts <[EMAIL PROTECTED]> wrote: > little by a) milestones: assuring that there is a known date when a > given ticket will be looked at Let me clarify a little: "looked at" doesn't necessarily mean "integrated", it may be deferred to the nex

Re: 1.0.1 release blockers?

On Nov 5, 1:35 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Tue, Nov 4, 2008 at 11:04 PM, mrts <[EMAIL PROTECTED]> wrote: > > > Most other projects are managed by a priority queue and clear target > > set for releases ("this has to go in

Re: 1.0.1 release blockers?

On Nov 4, 2:33 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > Yes, there is a reason, and it has been given several times in recent > history. The v1.0.1 milestone has not bee created in Trac because it > will not in any way help us deliver the v1.0.1 release. There is no > difference betw

String freeze for 1.0.1?

Shouldn't we have a string freeze before the 1.0.1 release (e.g. both #8882 and #9493 bring in new error strings)? Otherwise translators have to either continuously update the translations as new strings land or accept that 1.0.1 is released without complete translations. --~--~-~--~~

Re: 1.0.1 release blockers?

On Oct 31, 5:19 pm, "Joey Wilhelm" <[EMAIL PROTECTED]> wrote: > I would like to suggest the following: > http://code.djangoproject.com/ticket/9245 > http://code.djangoproject.com/ticket/6710 > > They both have fully functional patches... although granted the second has > no tests. IMHO http://cod

1.0.1 release blockers?

There has been much reluctancy in letting triagers tag and prioritize 1.0.1 milestone tickets. Now that 1.0.1 is really close, can we perhaps discuss what are the things that really should be fixed before it is released? The only major issue I have encountered is http://code.djangoproject.com/ti

Re: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend

On Oct 27, 6:57 pm, mrts <[EMAIL PROTECTED]> wrote: > On Oct 27, 5:16 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > > As others have pointed out, this isn't an issue with Django.  The > > easiest solution is to make this error less common with a hig

Re: "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend

On Oct 27, 5:16 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > > As others have pointed out, this isn't an issue with Django.  The > easiest solution is to make this error less common with a higher > timeout.  In settings.py: > > DATABASE_OPTIONS = {'timeout': 30} Thanks Brian, increasing the timeou

"OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend

It seems that current DB lock management doesn't play nice with the new Python 2.6 multiprocessing package and SQLite. See [1]. The same error also popped up in Google search under mod_python [2]. I wasn't able to reproduce this with MySQL. [1] http://code.djangoproject.com/ticket/9409 [2] http

Distutils/packaging sprint this weekend

In context of the Django community apps and app object discussions we had some time ago, there's a sprint upcoming tomorrow: http://mail.python.org/pipermail/python-dev/2008-October/082971.html http://www.openplans.org/projects/plone-conference-2008-dc/distribute This is a good occasion to speak

Re: Re-thinking model validation

On Oct 7, 12:08 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Mon, 2008-10-06 at 15:27 -0700, mrts wrote: > resolution on updates. The multiple simultaneous writes to the exact > same piece of data is only one corner of the full domain space. We plan > for the worst,

Re: Re-thinking model validation

On Oct 6, 2:03 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sun, 2008-10-05 at 14:11 -0700, mrts wrote: > > Looking at the path Honza has taken [1], it looks that it both > > complicates things and causes overhead -- for every constraint on > > an model o

Re-thinking model validation

Looking at the path Honza has taken [1], it looks that it both complicates things and causes overhead -- for every constraint on an model object, an extra db call for checking it is made, instead of relying on the constraint checks enforced by the db backend and corresponding exceptions during `sa

Re: Re-thinking model validation

mrts wrote: > Looking at the path Honza has taken [1], it looks that it both And the missing reference is [1] http://code.djangoproject.com/ticket/6845 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups &quo

Re: #6845 - model validation DDN

Hi Honza, thank you for your work on model validation! What's the status? Getting model validation in (if the powers that be agree) would help to fix a couple of annoying bugs listed below that are present in 1.0. http://code.djangoproject.com/ticket/9039 http://code.djangoproject.com/ticket/888

Re: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.

On Jul 1, 1:02 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > I've implemented iterable HttpResponse > in the first place out of purely practical reason: web server times out > if a particularly long file was passed into an HttpResponse. And also it > was really slow and was consuming all the memo

Re: Call for comments: CommonMiddleware (and others) break streaming HttpResponse objects.

On Jul 4, 2:26 am, Tai Lee <[EMAIL PROTECTED]> wrote: > > The only thing that might be worth doing in this are is adding a way to > > say "middleware should never be called on this response" and then > > somebody can write their own HttpResponse subclass and be in complete > > control of their des

Re: Proposal: app objects

On Sep 18, 2:56 am, zvoase <[EMAIL PROTECTED]> wrote: > I think the app object thing is a really good idea, but I have to say > one thing; why not see if some middle ground can be met between the > Django cheeseshop idea (going on in another thread in this group) and > this. That's the point. B

Re: Proposal: app objects

On Sep 17, 11:13 am, mrts <[EMAIL PROTECTED]> wrote: > I just copy-pasted the app objects requirement as listed and discussed > inhttp://code.djangoproject.com/wiki/InstalledAppsRevision. I > personally have no use case for it. Doh, that should have been *multiple* ap

Re: Proposal: app objects

I just copy-pasted the app objects requirement as listed and discussed in http://code.djangoproject.com/wiki/InstalledAppsRevision . I personally have no use case for it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups

Re: I want a pony: Django Cheeseshop

On Sep 16, 2:10 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Tue, 2008-09-16 at 00:16 -0700, mrts wrote: > > Let me try to wrap this up: > > > * there seems to be a general consensus that amending setuptools to > > create Django-specific extensions is

Re: I want a pony: Django Cheeseshop

10, 9:00 pm, "Brett Hoerner" <[EMAIL PROTECTED]> wrote: > On Wed, Sep 10, 2008 at 11:20 AM, mrts <[EMAIL PROTECTED]> wrote: > > And it doesn't handle project-local installation (arguably this > > can be done with virtualenv, but that will just clutter user-sp

Re: I want a pony: Django Cheeseshop

On Sep 10, 8:00 pm, Steve Holden <[EMAIL PROTECTED]> wrote: > I don't see why Django can't be just as much a part of the Python > community as, say, Zope, who frequently distribute code through PyPi. I > don't see the advantage of fragmenting the infrastructure. That's what > it's there for - supp

Re: I want a pony: Django Cheeseshop

On Sep 10, 7:12 pm, "Eric Holscher" <[EMAIL PROTECTED]> wrote: > your django apps. There is no reason to reinvent the wheel here, especially > after what Mark talked about at Djangocon (Django being considered seperate > from the Python community). Although I don't know anything about the talk, t

  1   2   >