Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/21/2010 11:49 AM, Mikhail Korobov wrote: 2. Does TemplateResponse allow pretty exception pages or not? Is Ben's issue resolved? I'll look into it this evening (MSD). -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this g

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/21/2010 03:22 PM, Ivan Sagalaev wrote: On 10/21/2010 11:49 AM, Mikhail Korobov wrote: 2. Does TemplateResponse allow pretty exception pages or not? Is Ben's issue resolved? I'll look into it this evening (MSD). So I did. There are actually two problems: - Exceptions i

Re: Gentle Proposal: add 'render' shortcut in 1.3

Hi Russel, On 10/22/2010 05:20 AM, Russell Keith-Magee wrote: Jacob has already marked #9886 RFC, and on first inspection, the patch looks good to me too; I want to have a closer look before I commit, though. If you want to proceed assuming that #9886 will be committed (i.e., make the fix for #1

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/25/2010 04:33 PM, Russell Keith-Magee wrote: * The problem with messages is a big one -- probably even a show-stopper if we can't find a way to reconcile the general use case that it represents (i.e., we don't just need a fix for contrib.messages -- we need to explain how/why the problem

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/27/2010 04:55 PM, Mikhail Korobov wrote: 1. 'Border' middleware is a backwards-compatible change, the requirement to bake response in middleware isn't. The difference is only that you propose to execute 'bake' in the end of response cycle and I propose to execute it at the beginning of the

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/28/2010 12:24 PM, Mikhail Korobov wrote: The request handling code have to be put into WSGIHandler and into ModPythonHandler so I'll wait until the patch for http://code.djangoproject.com/ticket/9886 will be landed. I'd say it's even worth to wait for http://code.djangoproject.com/ticke

Re: Gentle Proposal: add 'render' shortcut in 1.3

Russel: Wouldn't it make sense to put a flag on the TemplateResponse that prohibits accidental baking? Mikhail: So maybe it will be better not to make bake/force_bake public so that users won't be able to shoot themselves in the foot? I don't think it's doable at all. People still can call a

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/29/2010 09:58 AM, Russell Keith-Magee wrote: I agree that it's important to treat people as grown ups. However, this is something that is trivial to do by accident -- for example, printing response.content would be an obvious debug step -- and it will be a non-trivial thing to identify that

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/29/2010 09:38 PM, Carl Meyer wrote: Seems that a template-response-middleware might reasonably want to look at some other response data (headers? or simply extra annotation attributes?) in order to make decisions about what to do. You right. And it's not feasible (or beautiful) to just ri

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 10/30/2010 10:47 PM, SmileyChris wrote: It seems a simple enough proposal that trying to access the content property would raise an error until it is explicitly baked. Problem solved. True. I seem to somehow missed it between the lines. Thanks! I'm +1 on it by the way. -- You received thi

Re: Django/CherryPy problem with POST data

On 11/01/2010 03:06 AM, Russell Keith-Magee wrote: Sounds like a ticket is called for. Mark, can you also CC: me ('isagalaev') on this ticket. I have an idea where it can be broken. I remember that the initial patch was always passing a `size` parameter into .read() of the underlying stream

Re: Django/CherryPy problem with POST data

On 11/01/2010 08:44 AM, Russell Keith-Magee wrote: The only changes I'm aware of making were related to getting readline() to behave correctly. The patch as submitted didn't return the right values for the readline(len) case. Which call to read() are you saying is wrong? Sorry, my memory has fa

Re: Django/CherryPy problem with POST data

On 11/01/2010 11:21 AM, Mark wrote: Ticket #14594 From a quick look it can be fixed in two ways: - HttpRequest.raw_post_data can always explicitly ask for content_length bytes. If content_length is absent just treat it as 0. - WSGIRequest can wra

Re: Gentle Proposal: add 'render' shortcut in 1.3

On 11/02/2010 05:27 PM, Mikhail Korobov wrote: I'm quite busy now and don't think I'll be able to make the patch ready by 1.3 alpha 1. Full feature freeze is expected only by the time of beta so I don't think it's absolutely necessary to push it before alpha 1. Anyway since I care very much

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 11/28/2010 10:13 AM, Russell Keith-Magee wrote: For your consideration, I present a patch to resolve #12815 and #12816, adding a TemplateResponse and a render() shortcut. Thank you! - The render() shortcut doesn't use TemplateResponse. Since render() and TemplateReponse() have exactly th

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 11/29/2010 02:58 PM, Russell Keith-Magee wrote: My counterargument would be this -- if you use TemplateResponse, there's no need to use a shortcut at all. Yes, this is what I understood from your reasoning. I'm concerned more with documentation. Namely, what are we going to suggest for usag

Re: .limit() on a QuerySet

On 11/29/2010 11:31 PM, Christophe Pettus wrote: Before I put any work into this, I want to know if (a) I'm missing something super-obvious in the QuerySet functionality, or (b) this idea has already been explored and rejected. Hi Christophe, Looks like you're indeed missing queryset slicing

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 01:03 PM, Russell Keith-Magee wrote: I'd argue it doesn't simplify anything. It saves you a grand total of 10 characters (plus a couple more on import), but at the cost of the added complexity of having two ways of doing *exactly* the same thing. There is also a loss of explicitness

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 02:52 PM, Łukasz Rekucki wrote: Lots of people find render_to_response so verbose, that they are using direct_to_template() view instead. Django 1.3 deprecates that one, so it would be fair to offer those people a replacement. Forcing them at the same time into the world of lazy bak

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 04:26 PM, Łukasz Rekucki wrote: What about view decorators? I don't want to invent use cases here, but if I right now have a view decorator that on it's way out changes something that could alter how a template is rendered (like current language, some settings or the database conte

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

On 12/01/2010 05:05 PM, Łukasz Rekucki wrote: from django.conf import settings def without_localization(view): @wraps(view): def decorated(*args, **kwargs): # NOTE: I'm assuming this will actually have any effect - settings caching is a different issue old_value, sett

Re: Fetching results of a query set

On 12/12/2010 06:45 AM, Alex Gaynor wrote: Yes, if you're using iterator you'll have Django storing 100 items at a time. That being said I believe I read that some of the database wrappers do their own caching (it's either mysqldb or psycopg2, I dont' remember which). They both do. They have t

Re: Opinions on #15012 -- cache_page and TemplateResponse incompatibilities

Hi Russell, I seem to missed this email until lately… Here's my take on it if it still matters. On 01/05/2011 08:29 AM, Russell Keith-Magee wrote: 4) Modify cache_page to force a render of the response. This defeats the purpose of introducing TemplateResponse, and would mean that template r

Re: Homogenization of User and UserProfile

On 03/15/2011 01:49 PM, Michael A. Ryan wrote: In a typical client app, your User object is most likely one robust object which you have to express in Django as both User and UserProfile. It's kind of hard to talk about "typical" Django app because there are so many different of them :-). Howe

Re: Homogenization of User and UserProfile

On 03/18/2011 07:22 AM, Carl Meyer wrote: Don't use AUTH_PROFILE_MODULE or .get_profile(). As far as I'm concerned they bring almost nothing to the table except for the "there can be only one" restriction +1 Just use OneToOneField and the regular ORM access descriptors, and you can have as ma

Re: HttpRequest.read() issues

On 04/03/2011 07:03 AM, Tom Christie wrote: It's not very obvious from the docs or source if HttpRequest.read() can always be safely treated as a limited input stream, or if the developer needs to respect HttpRequest.META['CONTENT_LENGTH']. As far as I can tell the intention is that it can alway

Re: HttpRequest.read() issues

Graham Dumpleton: Silly question. Where is the proof that using a limited stream is a performance issue? Last night I actually did test it :-). You're right the difference in performance is less than a statistical deviation between different uploads over network. Tom Christie: Even so, presum

Accidental logging disabling

Hello everyone! I've found a (may be minor) bug with logging and I'm not sure how it can be fixed. Here's a stripped-down example showing the problem: The settings.py simply configures a single root logger: DEBUG = True DATABASES = { 'default': { 'engine': 'django.

Re: Accidental logging disabling

On 04/15/2011 02:20 AM, akaariai wrote: I have been using setup_environ in my projects, and the lazy initialization in can cause some weird problems, for example if you do manual timing using: start = datetime.now() access settings print 'Used %s' % (datetime.now() - start) You might get weird r

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/16/2011 04:30 PM, Carl Meyer wrote: in general, related-object access for reverse-FKs and M2Ms, contrary to the documentation, will _always_ use your default manager (actually, a dynamic subclass of it) It kind of makes sense. You don't want your deleted items to appear in results just b

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/18/2011 11:16 AM, Carl Meyer wrote: By "just this" I presume you actually mean just the second half of what you quoted ("explicitly set to False")? In other words, you're proposing to make use_for_related_fields work as advertised, but make it default to True instead of False? Not exactly

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/18/2011 11:45 AM, Johannes Dollinger wrote: I'd vote for (C). Deprecate `use_for_related_fields` and always use the default manager for related managers. Then add the possibility to specify custom mangers for individual relations: ForeignKey(Foo, related_manager=RSpecialManager)

Re: Accidental logging disabling

On 04/18/2011 08:25 AM, Carl Meyer wrote: FWIW, I don't think changing settings in general to be non-lazy is an option - it will suddenly make a bunch of parts of Django dependent on DJANGO_SETTINGS_MODULE at import time, where currently they only require it at runtime (and even then perhaps only

Re: #14891, a.k.a. "related managers don't work how we claim they do"

On 04/18/2011 02:59 PM, Carl Meyer wrote: Hmm. Why does it make sense for OneToOneField lookups to behave differently from *_set managers? If I've got a default manager that hides "deleted" objects, for instance: why should deleted objects by default "not exist" when I traverse a reverse FK, but

Re: RFC: new backports policy

On 04/19/2011 02:35 PM, Daniel Moisset wrote: I'm using 1.3 in production and there's a bugfix I really want, so I do the backport (and write the code, tests, docs). If I submit this to the issue tracker, is there a chance my patch will get into the next minor release, or you won't even consider

get_field_display: Django needs a template filter to allow get_field_display for a dynamic field name

return getattr(value, arg)() else: return getattr(value, arg) else: try: return value[arg] except KeyError: return settings.TEMPLATE_STRING_IF_INVALID Here's the corresponding ticket: https://code.djangoproject.com/ticket/1603

Re: __getattr__ on SimpleTemplateResponse causes problems

Though the patch in the ticket does solve the problem I completely agree with removing the code altogether… I'm not a fan of "helpfully" reformulating exceptions while trying to be more specific. In practice it hurts more than it helps, and this case is just another confirmation. -- You receiv

Re: Little help with #6886 ("Assigning a Model Instance to a Foreign Key Attribute Doesn't Cache the Instance")

Jacob Kaplan-Moss wrote: > So, a proposal: I'd like to change FK assignment to be "special" like > you suggested. I'd like to: > > * Raise a ``ValueError`` if you try to assign an object of the wrong > type to a FK. Why not defer it to save()? Currently you can assign invalid values to other fi

Re: Django releases

James Bennett wrote: > If that means organizing a sprint or two on it > and then doing a trunk merge to get more eyeballs on the code, then > let's do that instead. +1 for early merging. Merging qs-rf helped (forced :-) ) many people to catch many bugs that won't ever be found on the branch due

Re: Introducing ModelView, a RESTful class-based view of your resources

David Larlet wrote: > This is not a secret that I'm interested in both Django and Semantic > Web. I'm following discussion about Django+REST for more than two > years and when I realize that newforms-admin branch will use class- > based generic views [1], I decided that it's probably the righ

Re: RFC: Django 1.0 roadmap and timeline

Jacob Kaplan-Moss wrote: > Django 1.0 will be released in early September. Ouch... To paraphrase Joel Spolsky "If you have a hand-wavy feature called "1.0 release" and you schedule 3 months for it, you are doomed". Jacob, honestly, where this date has come from? It can as easily be August or O

Re: RFC: Django 1.0 roadmap and timeline

Ville Säävuori wrote: > Firstly, as Jacob said, the schedule is just a draft at this point. > But I'm very much +1 on locking down spesific dates for any given > milestone. It's vital to have firm schedule and dates for making it > all happen in a relatively short period of time. If this is vital

Re: RFC: Django 1.0 roadmap and timeline

Jacob Kaplan-Moss wrote: > I didn't, though, just plunk a date three months out; the idea is to > take about a month to get to the alpha -- that is, one month to finish > the blocker features (but not necessarily make them bug-free), then > two weeks to the first beta, then a week each between eac

Re: RFC: Django 1.0 roadmap and timeline

Ville Säävuori wrote: > The point of deadlines are that people tend to try to make them come > true. If there is something that I've learned as a project manager > during all the years that I've worked as one, it's that deadlines are > important. My main point was that the deadline should be real

Re: Django community aggregator and non-English posts

Tom Tobin wrote: > Except it *is* a problem when I'm forced to deal with a regular influx > of what is, to me, *noise* in my aggregator. Tom, sorry, you're fighting with this so hard that I couldn't resist to propose another solution for you! Pick a language that annoys you the most and... star

Re: MS SQL backend as a proper external backend (was: RFC: Django 1.0 roadmap and timeline)

> To solve it I proposed[1] another strategy: delegate type conversion > to the backend. Otherwise, I think we will end with too many backend > flags. +1 I maintain the external Firebird backend and I would also prefer this solution. Ivan I

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

Tai Lee wrote: > http://code.djangoproject.com/ticket/7581 > > Just posted this ticket with an initial patch (sans documentation > changes and tests). Basically there are several middleware classes > that access HttpResponse.content directly which break streaming > HttpResponse objects that use a

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

Malcolm Tredinnick wrote: > I thought we'd fixed it, but apparently we haven't: if any iterator is > passed into an HttpResponse, it should be converted to a string > immediately so that things can index into it without doing > non-repeatable consumption. Malcolm, sorry, that won't work. I've imp

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

Malcolm Tredinnick wrote: > Any middleware that examines the content has to pull the content into > memory in case it's an iterator. If they don't they're buggy because > they're consuming the content ahead of the web server. Agreed. > But the default behaviour shouldn't > require repetitive pra

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

Malcolm Tredinnick wrote: > The response should just return a copy of the > content when response.content is accessed, which means turning any > iterator into a proper string. Ouch.. I thought it already does just that. Yeah, it's a bug then. Though simple to fix. > But it *does* require that e

Moscow local sprint

Hello! We at Yandex have decided to host a local sprint in Moscow, Russia during the EuroPython Django sprint [1]. I invite Django developers in Moscow to come and participate! (Though chances that you've already heard about it :-) ) [1]: http://company.yandex.ru/blog/message.xml?msg=102921

Declarative syntax for widgets in ModelForm

Hi, everyone! I was recently refactoring some old code to use a ModelForm and was stuck at an issue that we don't have a simple way to say "this form has these fields from a model but with other widgets". For example I have an Article model that I want to edit in a form: class ArticleFor

Re: Correct URL paths and compromises (ticket #285)

Malcolm Tredinnick wrote: > >PythonHandler django.core.handlers.modpython >SetEnv DJANGO_SETTINGS_MODULE mysite.settings >... > > > >PythonHandler django.core.handlers.modpython >SetEnv DJANGO_SETTINGS_

Re: Declarative syntax for widgets in ModelForm

Steve Holden wrote: > What's CSS for? For styling. Choosing widgets has nothing to do with styling. My cols and rows for textarea is just an example that, incidently, can be emulated with CSS. But often you want to use a different widget altogether, say, a set of radio buttons instead of defau

Re: Declarative syntax for widgets in ModelForm

Yuri Baburov wrote: > And before it's landed into the trunk (i hope it will ;) ) you can > make your own subclass of ModelForm which does exactly what you > proposed, and then subclass it everywhere ;) Yuri, it's a bit redundant note :-). Sure everyone can subclass anything or patch Django insta

Re: Correct URL paths and compromises (ticket #285)

Malcolm Tredinnick wrote: > No, SCRIPT_NAME would be more or less /site_prefix/ in the first case > and /admin/ in the second case. Ok, got your point. I now understand why you wanted SITE_PREFIX as a parameter for patterns(). > But we do have to be consistent. PATH_INFO does not include any >

Re: Declarative syntax for widgets in ModelForm

Michael Elsdörfer wrote: > Why stop at widgets? Basically, because I was struggling with widgets many times but didn't have any practical needs for changing a label, for example. I don't say it's useless or something but I just can't defend it from my experience. > By the way, IIRC the followi

Re: #7666: Default managers should not restrict access to single related objects

Adrian Holovaty wrote: > This is certainly a bug. The main question is how to fix it. Oh, it's a big can of worms, actually. I was once pondering on this and found some tricky cases. 1) Managers are not just restrict querysets by filtering. They can be used for example to produce custom querys

Re: django.contrib.sessions problems

Malcolm Tredinnick wrote: > The rest of the conversation should > proceed on the assumption that the bug about creating unique database > entries will be fixed first. Now I think that the problem is only exists if one uses non-transactional DB setup. In this case due to race conditions one of th

Re: Reminder: "Must-have" feature freeze in two weeks

Jacob Kaplan-Moss wrote: > Hi folks -- > > This is your friendly reminder the three "must-have" features on the > roadmap are due on two weeks -- Django 1.0 alpha is due for release on > July 20th. > > We've got two sprints between then and now (see > http://code.djangoproject.com/wiki/Sprints)

UploadedFile in cleaned_data

I've seen already two people highly confused with this thing. After successful validation of a form with file upload form.cleaned_data['fieldname'] contains an instance of a wrapper -- newforms.fields.UploadedFile. People confuse it with the real core.files.uploadedfile.UploadedFile which is a

Re: Will oldforms completely go after 1.0?

Russell Keith-Magee wrote: > At some point between now and v1.0 final, newforms will be renamed to > forms BTW... I sometimes think that "newforms" has become such a recognizable term that may be it makes sense not to rename them? --~--~-~--~~~---~--~~ You receiv

Re: UploadedFile in cleaned_data

Marty Alchin wrote: > This was reported in #7614, and fixed in [7859], so if you get a new > copy of trunk, it should be all set. Oh... Thanks for the heads up! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Djang

Re: Add a helper function in UploadedFile's API for writing files on disk?

Malcolm Tredinnick wrote: > The docs already mention looping over chunks(). However, given that the > file exists on disk (which is something you can check for), and you have > access to the full filename, it seems like for simple file copies/moves, > using the standard Python shutil module solves

Re: ANN: Join us at a sprint!

Jacob Kaplan-Moss wrote: > If you're interested, check out > http://code.djangoproject.com/wiki/Sprints, and see the details of > each particular sprint: > > * July 18: Sausalito, CA: > http://code.djangoproject.com/wiki/SprintSausalitoJuly2008 > * August 1: Location TBA, probably in the

Re: ANN: Join us at a sprint!

Jacob Kaplan-Moss wrote: > I figured that since it's already started those who're going to go are > already there. Sorry I didn't get around to announcing it sooner! Ah... Ok. One more question. Contrary to what the sprint page says, newforms-admin wasn't merged last weekend, but I think it doe

Results of Moscow local sprint (newforms-admin and Oracle pooling)

Hello! Last Saturday we've gathered in Moscow at Yandex and had a sprint aimed at newforms-admin bugs. It didn't work as smooth and effective that we hoped but all the problems are more or less explained by the lack of my experience as a sprint organizer. We'll try harder next time! Nonethel

Re: Is URL template tag's syntax going to change?

Julien Phalip wrote: > Hi, > > For months, there has been a mention in the url tag's documentation: > > "Note that the syntax for this tag may change in the future, as we > make it more robust." [1] > > Is that mention still relevant for 1.0 and beyond? If I recall correctly, there was a discu

Re: Is URL template tag's syntax going to change?

Johannes Dollinger wrote: > Afaics the only other tag that would accept an arbitrary unquoted > literal is {% ssi %}. > Are there more? Actually when I've first implemented {% url %} I looked for formatting parameters at {% cycle %}. Which back then had only one syntax: {% cycle val1,val

Re: Call for testing: new docs

Jacob Kaplan-Moss wrote: > I've also put a built version of the docs online at > http://docs.djangoproject.com/dev/. There are some problems with the > version online right now; no need for bug reports since I'll be > changing the online version to better fit into the django site over > the next f

Re: ANNOUNCE: Django 1.0 released

dankelley wrote: > In other words, should I (or typical users) download the official 1.0 > version, or will it still be advised to track the development version? I've answered in django-users, seems more appropriate. --~--~-~--~~~---~--~~ You received this message

Re: Proposal: {% doctype %} and {% field %} tag for outputting form widgets as HTML or XHTML

Simon Willison wrote: > {% doctype "xhtml1" silent %} To me it looks a bit weird but I'm afraid my English is not apt to dare to describe it :-). May be this will look cleaner: {% doctype "xhtml1" "" %} E.g. instead of "doctype(mode, silent=False)" it's "doctype(mode, override='')" --~-

Re: Proposal: {% doctype %} and {% field %} tag for outputting form widgets as HTML or XHTML

Rob Hudson wrote: > To avoid adding yet another setting (unless it's warranted here) can > the setting of a doctype in a template tag set a value in > django.conf.settings that django.forms can then check (with a > reasonable default)? Why not just adopt {% field %} as a default way for rendering

Re: Proposal: user-friendly API for multi-database support

Simon Willison wrote: > * Simple master-slave replication: SELECT queries are distributed > between slaves, while UPDATE and DELETE statements are sent to > the master. It won't work on a statement-level. If you have a transaction and do an UPDATE and then a SELECT then the latter won't see

Re: Proposal: user-friendly API for multi-database support

Mike Malone wrote: > At Pownce, for example, we stick users to the master database for some > period of time (a couple of seconds, usually) after they post a new > note. Another approach that I took in mysql_replicated[1] is to serve a page that user GETs from a redirect after successful POST

Re: Proposal: user-friendly API for multi-database support

the same terminology again as a > keyword argument. > > If you wanted to control which master/slave connection was used from > your business logic, you'd do something like this: > > obj = Article.objects.using('master').get(pk = 4) > obj.name = 'Hello&#x

Re: Proposal: user-friendly API for multi-database support

Simon Willison wrote: > That's really interesting. I wonder if that invalidates the whole > approach I proposed, or merely means it needs some refining? As Malcolm has pointed you're proposing many things at once :-). I tend to think that replication, sharding, migration to another db are very

Re: Proposal: installmedia command - A story for distributing media with apps

Brian Beck wrote: > Distributing media with apps could be a lot easier. Currently this > requires copying or linking files manually (possibly each time the app > is updated), and this encourages developers to put CSS and JavaScript > inline in their templates. I propose a management command to m

Re: Postgresql transaction aborts, despite being in autocommit mode

[EMAIL PROTECTED] wrote: > It is also highly inefficient for Web applications (since > they most often do nothing transactional) and gets you into trouble in > error cases. I don't want to get into the argument about ticket 3460 itself but I just don't get this paragraph... What is special in we

Re: Postgresql transaction aborts, despite being in autocommit mode

Richard Davies wrote: > On the first question, I'd suspect that many pages of many (simple) > web applications just have a one-to-one mapping between the web page > and a single line of SQL on a normalized database - e.g. a page > listing all events (single SELECT), a page listing all people at an

Re: Postgresql transaction aborts, despite being in autocommit mode

Richard Davies wrote: > That's an interesting article, and I follow your logic. However, > Jack's original patch follows from profiling work he did on his > Chesspark site (see > http://metajack.wordpress.com/2007/07/25/do-you-know-what-your-database-is-doing/ > ) in which he claimed a 2-3x speed

Re: Declarative syntax for widgets in ModelForm

Joseph Kocherhans wrote: > On Sun, Jul 6, 2008 at 6:27 AM, Ivan Sagalaev > <[EMAIL PROTECTED]> wrote: >> ## Proposal >> >> To fix this I was thinking along the lines of: >> >> class ArticleForm(ModelForm): >> class Meta: >>

Re: Declarative syntax for widgets in ModelForm

SmileyChris wrote: > I've always just done this by doing: > > MyForm(ModelForm) > model = MyModel > def __init__(self, *args, **kwargs): > self.fields['name'].widget = Textarea() # or whatever You've forgot to call `super` :-). I know that it's only an example but it adds anot

Re: Declarative syntax for widgets in ModelForm

SmileyChris wrote: > I do feel like it leads to slippery slope though. LikeMichael said, > "why stop at widgets?" I often need to change labels and help text > too. Full customization already can be done by specifying fields directly in a form class. In my experience widgets are just very common

Re: Declarative syntax for widgets in ModelForm

Brian Beck wrote: > I think your model_field helper being built-in (short for > x._meta.get_field(y).formfield(**params), which is not very pretty) > would be the best solution here. In my experience, customizing just > the widget for a model field is just as common as changing just the > label,

Re: Proposal: Day of Week Filter in ORM on Date / DateTime Fields

Malcolm Tredinnick wrote: > I've been thinking through, with a couple of different people, how we > can support extra lookup types on fields and so I'm going to reserve > judgement on this particular implementation until I have some thoughts > in order on the latter subject. In my opinion this pa

Re: "things are ready" signal?

Marc Fargas wrote: > So, if you need to hook something that need to run *once* after django > loads (at any level) you need to either monkey-patch or patch Django > itself. For the record, there's a better (IMO) workaround: create an app with a models.py and put logic there. It will be loaded j

Re: GET requests should not alter data?

Amit Upadhyay wrote: > This is not about specs or what is allowed, rather what is there in > actual django. And about implementation goals for django. It is > possible to have a django(core+contrib apps shipped with django) with > only SELECT queries in response for GET request. So far I have > id

Re: GET requests should not alter data?

bo wrote: > It seems that what you may want is something like > > http://softwaremaniacs.org/soft/mysql_replicated/ > > (its in Russian that i cannot read and one of the links has the > source :) It has a link saying "English" right on top of the page :-). It's http://softwaremaniacs.org/soft/

Re: Customizing notification method for internal server errors

Jesse Young wrote: > The built-in behavior for > django.core.handlers.base.handle_uncaught_exception calls mail_admins > for each internal server error. > > So if a very high-traffic view has an internal server error, duplicate > emails will be sent at a very high rate. This isn't usually > desir

Re: GET requests should not alter data?

Amit Upadhyay wrote: > The crux of that solution is the middleware: > > def process_request(self, request): > state = request.method in ['GET', 'HEAD'] and 'slave' or 'master' > connection.use_state(state) > > Which is same as what I am talking about. I feel obliged to corr

Re: GET requests should not alter data?

Amit Upadhyay wrote: > 1. make sure none of your apps do db writes on GET. [It was the case > with my entire project already, other than one case, which was trivial > to work around]. > 2. Use non db session backend. > 3. Not use auth messages. [This presented some problems for me, but I > had luc

Re: Proposal: Optional {% default %} clause for the {% for %} template tag

Jannis Leidel wrote: > The proposed feature would allow this: > > {% for item in grocery_list %} > {{ item }} > {% default %} > Nothing to buy. > {% endfor %} As of coloring the bikeshed, I prefer {% empty %} over {% default %} and {% else %}. --~--~-~--~~~---~-

Bug in admin or in my model ?

I forget to write some details: OS: Debian Etch with python 2.4 Django version: 1.0, also tested on new 1.0.1 with same results -- Ivan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers"

Bug in admin or in my model ?

It looks like the bug #3924 which should be allready closed. -- Ivan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-

Bug in admin or in my model ?

eld(u"Zoom level", default=1, help_text=u"Zoom level ktory sa použije pri zoomovaní na objekt pri vyhľadávaní") sql_hladanie = models.TextField(u"Vyhľadávací SQL", blank=True) class Meta: ordering = ['kategoria','pora

Re: Bug in admin or in my model ?

Thanks, I will move to django-users for more details. On Saturday 15 November 2008 16:23, Karen Tracey wrote: > On Sat, Nov 15, 2008 at 5:57 AM, Ivan Mincik <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > I have a problem when adding record by Django Admin and I a

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

Adrian Holovaty wrote: > Yuri, to answer your question: I try never to send the request object > into a template context Uhm... But using RequestContext is not about it. Everyone I know uses RequestContext almost exclusively (i.e. nobody uses standard render_to_response with plain Context insta

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

Nathaniel Whiteinge wrote: > Yes. It's built into Django and already does exactly what some people > want render_to_response to do, so why all the hullabaloo? (Or am I > still missing something?) The problem here is for novice users. We have two things doing roughly the same thing which is confu

Re: Django & memcache hashing

Malcolm Tredinnick wrote: > Okay. If we go this path, it's something to include in Django, rather > than recommending yet another caching package. We either make it a > configuration option to force python-memcache or cmemcache or we just > "Do The Right Thing", with the latter being preferable.

<    1   2   3   4   5   6   >