Re: postgresql range types v2

Marco, this is great. I wonder if it would be possible to add range fields without modifying django? On Monday, December 31, 2012 8:56:12 PM UTC+11, mpaolini wrote: > > Hi all, > > sorry for the noise, forget my previous mail as it was pointing to the > wrong commit, > here's the good

Re: postgresql range types v2

Also, did you see psycopg2.extras.DateTimeRange? On Monday, December 31, 2012 8:56:12 PM UTC+11, mpaolini wrote: > > Hi all, > > sorry for the noise, forget my previous mail as it was pointing to the > wrong commit, > here's the good one: > > >

Re: Perception of attitude in tickets

Sorry I'm late back to the party boys and girls. Trivial as it may be, it's really just communication that's the only issue here, and I'm glad this has prompted a review. We all mean well and we're eager to help. The solutions Cal, Russ, Luke and co have discussed sound great. BTW- there

Deprecation a little harsh?

It's great all the housekeeping we've been doing lately, and I'm sure we all agree nice to have clean, tidy code; but I wonder if we've been a little too unforgiving at the expense of easy compatibility with important third party apps? Celery, sorl-thumbnail, mptt, registration, shorturls,

Re: Deprecation a little harsh?

On Monday, 12 August 2013 17:23:40 UTC+10, Aymeric Augustin wrote: > > It would be interesting to describe what actual problems these libraries > encountered. Were they caused by actual deprecations or by changes in > private APIs? > One example would be simplejson, why not leave a stub there

ValidationError for fields

Lack of clean control over field-specific form errors is an issue that has been raised and discussed many times over the years, but still the solution seems pretty inadequate. We're even directing people hack around with _errors and making excuses for it in the documentation.

Re: ValidationError for fields

es and it's accessible from outside the form, from a view > for example. > > The current patch only documents the dict construct for `ValidationError` > since `Form.add_errors` was a private method in my original patch; should > both be documented or only `Form.add_errors`? > > -- &g

Ticket 9360 get_fieldsets doesn't work as advertised

David Christensen raises a valid point in this ticket -- http://code.djangoproject.com/ticket/9360 Ubernostrum is right, as usual :-) get_fieldsets is definitely called for display; but not for save. So, what is the use case for this though? Why would you ever want to display an incomplete set

MySQL index hints

For those of us using MySQL, having large tables, whilst also wanting queryset goodness -- http://code.djangoproject.com/ticket/11003 It goes a little something like this -- Model.objects.filter(field=value).with_hints('my_index') All those in favour say I. Simon -- You received this message

Re: MySQL index hints

> If you can come up with answers to these points, I might get > interested. 1 and 2 are fairly trivial; I can think of some obvious > answers for 3, but 4 is the big problem, and will require some serious > research and consideration. Well, I'm glad you like the with_hints() approach. Items 1-3

Re: MySQL index hints

On Jul 5, 5:08 pm, hinnack wrote: > Thats interesting. > Can you explain, how the search keyword made it into the source? > Entry.objects.filter(headline__search="+Django -jazz Python") > SELECT ... WHERE MATCH(tablename, headline) AGAINST (+Django -jazz > Python IN

Re: MySQL index hints

> I would like to know how you're validating your assertion that MySQL > is the most used backend. It doesn't match my experience or > observation. Nobody knows for sure. I'd put my money on it though. > The fact that this is a MySQL-specific issue is perhaps the biggest > impediment to my

Re: MySQL index hints

Simon -- Slicing result sets is clearly the developer's responsibility IMHO. Even with hard limits, MySQL still fails miserably in many situations; hence the proposal to support hinting from the ORM. Russ -- Firstly, re namespacing. No worries, let's just keep it RDBMS- specific, ie -- MySQL

Error email flooding on high traffic production sites

Hi all Default behaviour of sending an email on 500 error is great. Problem is on high traffic sites, and you might just be making a quick update- literally within seconds you can bring your mail server down- crash your mail client- or render your gmail account useless. With "batteries

Permission support for admin inlines

The ModelAdmin's permission hooks are great- has_add_permission, has_change_permission, and has_delete_permission. It would be nice if they were supported by inlines in the same way; ie InlineModelAdmin, StackedInline, TabularInline, GenericStackedInline, GenericTabularInline. UI is fairly

Custom FilterSpecs

Honza's #5833 is nifty. It's a pity it missed the cut last year for 1.1. It's been kicking around for 3 years, and there seems to be plenty of similar tickets that it'd address too. Any chance for 1.3? Is it just the lack of tests/docs or are there design concerns? -- You received this message

Default project layout / directory structure

Who votes we should come up with a django-blessed 'official' default project layout / directory structure? Might sound like a triviality, but sometimes it's the little things. 1. Newcomers -- startproject throws 9/10 into confusion and results in a messy first few projects. 2. Gurus --

Re: Default project layout / directory structure

On Mar 15, 9:46 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Fri, Mar 11, 2011 at 1:14 PM, Simon Litchfield <si...@s29.com.au> wrote: > > Who votes we should come up with a django-blessed 'official' default > > project layout / directory structure?

Re: Time for a new release?

Seems reasonable to me On Aug 26, 1:21 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > Hi guys, > > I've been wondering of late if we need to cut a new release. I have a > few reasons: > > 1) Its been six months since the release of 0.96, and we've made some > good progress since then; >

Re: Looking for discussion on #5535

James Bennett said the following: > >>> my_id = 3 > >>> UserProfile.objects.create(user_id=my_id) #works > >>> UserProfile.objects.get(user__id=my_id) # works > >>> UserProfile.objects.get_or_create(user__id=my_id, defaults={'user_id': > >>> my_id }) #works That's it, right there in a

Re: Looking for discussion on #5535

Gary Wilson wrote: > This is a tricky way around django.db.models.base.Model.__init__'s current > enforcement of the foreign key field (without the _id) wanting an instance, > but shouldn't be needed if we implement the above (meaning create() would act > like get() in that you could pass either

Re: Looking for discussion on #5535

Seems Collin, I and co will have to agree to disagree on this. It's all relative I guess, you think we're upside down, I think you're upside down :-) Just a shame to burn thousands of man hours on something which is so plainly inconsistent to fresh eyes. Collin Grady wrote: > James Bennett

Re: Another urlpatterns proposal (add method column)

Personally I haven't found the need for this, since I don't lay things out like that. However, using the new-ish urlpattern url() notation would be the go here. Just bung a new kwarg on url.__init__() with a default of something like None, ALL or *, that would optionally accept values like GET,

Models to keep a copy of their last saved values?

When we load/save a model to/from the database, wouldn't it be nice if the model kept a copy of those 'last saved' values, as say myinstance.original.myfield, or myinstance.last_saved.myfield etc. Internally, we could then make the UPDATE/INSERT statements only include the rows that have

Re: Models to keep a copy of their last saved values?

On further inspection, it looks like this could be just a couple of one-liner additions to db/models/base.py. self.db_values = db_values On Dec 11, 3:09 pm, Simon Litchfield <[EMAIL PROTECTED]> wrote: > When we load/save a model to/from the database, wouldn't it be nice if > th

Add newform errors directly (without using ValidationError)

I tend to think there needs to be a documented, 'clean' way of adding non_field_errors (and even field errors too) to forms, *outside* the clean() methods. Currently, I believe the only 'right' way to add errors is by raising a ValidationError. This is suitable for 'contained' and relatively

Newforms DateField/DateTimeField initial value rendering

No control is given over how initial date/datetime values are rendered, using DateField/DateTimeField. Clients don't like -MM-DD; who can argue? At the very least, I propose we at least allow an optional display_format string, kinda like input_formats. More importantly though, I think we

Re: If form_for_model is deprecated, what is its replacement?

On Apr 8, 5:19 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > form = ModelForm(model=Person, exclude=["pay_grade"]) Looks fine to me. Any reasoning against? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups

Re: Newforms DateField/DateTimeField initial value rendering

> I haven't tried to use it, but couldn't a DateTimeInput widget with those > fields > solve the problem? It accepts a format arg which is how it will render its > data > - combined with the right input_formats in the field, it stands to reason that > would work :) Yes you're right, so we can

Re: Newforms DateField/DateTimeField initial value rendering

On Apr 9, 11:56 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > they share the same longitudes. But it is reasonable to do it based on > locale (including using the default locale setting). Using the locale setting sounds great. Need any help?

Reload method for models

Anyone who mixes the ORM with raw data-modifying SQL concurrently may well be in for a surprise. Scenario. Load your model; run your data-modifying SQL; then explicitly try to reload your model to refresh it's data. Gotcha. The inbuilt queryset cache will cleverly skip straight over your attempt

Re: Reload method for models

Lazy-loading sorry, not 'caching' --~--~-~--~~~---~--~~ 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,

Static vs variable test fixtures

Reloading of fixtures for each test gets painful when the fixtures get big. Maybe we could continue to have TestCase.fixtures as a list of 'variable' fixtures that do definitely need to be reloaded for each test... and add a new optional attribute, TestCase.static_fixtures, which would be a list

Re: How do you handle cascading deletes in your production apps?

+1. Definitely need some kind of cascade=False option somewhere. I'd argue it should be the default. I have some production horror stories which I'm sure I don't need to share. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google

Silencing TemplateSyntaxError

How about a setting to silence TemplateSyntaxErrors? Have the node renderer just return an empty string instead? Might sound a bit loose, and obviously this isn't for us Django guys. It's for regular HTML guys -- - They could make simple template edits to sites without fear of bringing the

Remove contrib redirect's dependency on sites

Contrib redirects is still a handy little app, but it's dependency on contrib.sites is often unnecessary and a little annoying. Would anyone else be keen to see the dependency removed, gracefully? If so I'll spin up the code. -- You received this message because you are subscribed to the