Remove contrib redirect's dependency on sites

[Simon Litchfield]

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 Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6bd7adfc-13e6-46f7-aec3-d1b84243e2e9%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: ValidationError for fields

[Simon Litchfield]

An improvement for sure. Any reason it can't be a little more pythonic, ie 
using optional kwargs etc?

My only concern is in having two ways of achieving the same thing. If the 
latter is simpler and more flexible, does this place our entire 
ValidationError approach to handling form and model errors in question? 
Hmmm. Maybe we can come back to that later :-/


On Tuesday, 20 August 2013 14:11:44 UTC+10, Loic Bistuer wrote:
>
> There is a ticket with a PR to address the issue of targeting specific 
> fields when raising errors; I'm awaiting feedback on what should be the 
> documented API. 
>
> https://code.djangoproject.com/ticket/20867. 
>
> This patch enables two patterns: 
>
> - Raising ValidationError({'field': 'error'}) from `Form.clean()`. 
>
> - Calling Form.add_errors('field', 'error') from anywhere. 
>
> The former is actually something that existed for a long time; only it 
> couldn't be used from `Form.clean()`. This pattern allows targeting 
> specific fields from the `Model` layer (see #16986). 
>
> The later has been proposed by @akaariai and @mjtamlyn, it's easier to use 
> for the simple cases 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`? 
>
> -- 
> Loic 
>
> On Aug 20, 2013, at 7:58 AM, Simon Litchfield 
> <litch...@gmail.com> 
> wrote: 
>
> > 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. 
> > 
> https://docs.djangoproject.com/en/dev/ref/forms/validation/#form-subclasses-and-modifying-field-errors
>  
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

ValidationError for fields

[Simon Litchfield]

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.
https://docs.djangoproject.com/en/dev/ref/forms/validation/#form-subclasses-and-modifying-field-errors

What about an optional kwarg on ValidationError? Eg, raise 
forms.ValidationError('This field is seriously not cool', field='myfield'). 
Current 
behaviour as-is.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecation a little harsh?

[Simon Litchfield]

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 that imports 
json? IMHO that was a little draconian and needlessly broke several third 
party apps.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Deprecation a little harsh?

[Simon Litchfield]

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, compressor, tinymce 
(I could go on) have been having trouble keeping up. 

One of Django's key strengths is the large collection of apps. Some aren't 
as regularly maintained as we'd like but we still love them. Is it a little 
unreasonable to expect them all to move so fast?

Any one else found themselves spending too much time lately patching other 
peoples' stuff?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Simon Litchfield]

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 are two Simon's here. I'm "simon29" from the original ticket, 
not "Simon" from this thread.


On Saturday, 11 May 2013 03:00:04 UTC+10, Simon wrote:
>
> Hi,
>
> When I started using Python a couple of months ago, a quick Google for 
> frameworks turned up a lot of results for Django so I decided to give it a 
> spin.
>
> I'd like to give some feedback on my experience to date. There are a lot 
> of features I really love, some that are a little quirky and some that are 
> downright inflexible. None of this will be news - it's the same for every 
> framework. That said, I started to have doubts when I was attempting to 
> find solutions/workarounds to the problems I encountered.
>
> Today was the 5th or 6th time that I've ended up at the ticket system and 
> seen people saying "This would really help me" and a core developer saying 
> "I don't see the need" (rather arbitrarily IMHO) and closing as wontfix. 
> This is invariably followed by people asking for reconsideration which in 
> turn gets a "use the mailing list" with varying degrees of rudeness.
>
> While I'm sure it's not the real reason, sending people to the mailing 
> lists feels like a way of brushing disagreement under the carpet. There's 
> no obvious way to follow on from the discussion in the ticket to the 
> relevant discussions in the mailing list (if any) and visitors coming by 
> years later now have to go and hunt through an archive to find out if 
> there's any chance of a change.
>
> I feel that the general attitude expressed in some of the tickets is poor. 
> The one which prompted this post is 
> https://code.djangoproject.com/ticket/901. I think comment 
> 20 is 
> a good demonstration of my point. A couple of users were getting frustrated 
> at the lack of discussion/progress which resulted in a fairly sanctimonious 
> rant. 
>
> Some other tickets I've ended up on have proposed patches and seem to have 
> sat in "Design decision" for years, which again gives the impression that 
> the core team didn't like it so just sort of ignored it until it went away.
>
> So, to be honest, the impression I'm getting WRT new features in Django is 
> "Don't bother proposing it 'cos it's not going to happen".
>
> There are 
> StackOverflow
>  
> questions
>  
> (another)
>  on 
> the topic and numerous other sources pointing at this particular ticket 
> wondering why it hasn't been implemented. The only reason I can see is that 
> "jacob" wasn't convinced by the (first) use case.
>
> Now, I admit that I'm probably seeing the worst side of the problem, there 
> are probably hundreds of other features which did get in (which is why 
> there's documentation not tickets for me to find) but that doesn't make the 
> situation I'm seeing better, just smaller.
>
> Perhaps the fact that people keep posting on closed tickets shows that the 
> current flow to the mailing lists isn't a good one? Maybe either add a 
> "Start a topic about this ticket" link or maybe even just allow discussion 
> to continue on the ticket as many others do?
>
> I'm unlikely to use Django moving forward. There are a number of reasons 
> and I'd be lying if I said this was the biggest but it was a factor in my 
> decision.
>
> Anyway, I wanted to take a few minutes and share the impressions I've had 
> to date - perhaps this way, others will have a better experience in future.
>
> Thanks for reading
>
> Simon
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: postgresql range types v2

[Simon Litchfield]

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: 
>
>
> https://github.com/mpaolini/django/commit/b754abdeab204949510500ccb1b845b7ad143542
>  
>
> copying here the rest of the original mail: 
>
> postgresql since version 9.2 added support for range types [1] 
> they have a nice set of specialized operators like "overlaps", "left of", 
> etc... [2] 
>
> So I decided to work on a reference implementation for Django 
> even if it looks like psycopg2 does not fully support yet these data types 
> [3] 
>
> The implementation is only a proof of concept and is not complete and not 
> tested 
> (but it does contain tests, of course!) 
>
> I did: 
>   - datetime range python data type: two bounds plus inclusive/excusive 
> info (very basic!) 
>   - datetime range model field 
>   - range specific lookups for querysets 
>   - non-overlapping constraint: db-level enforced with sql CONSTRAINT and 
> model validation 
>   - some documentation 
>
> TODO: 
>   - form, widget, modelform, localization, admin 
>   - more range types (int, bigint, etc...) 
>   - more validation against invalid ranges 
>   - better range type python implementation 
>   - more testing 
>
> Do you like it? Any chances for it to land in master once it is completed? 
> Or is it too specialized? 
>
> Cheers, 
>
> Marco 
>
> [1] http://www.postgresql.org/docs/9.2/static/rangetypes.html 
> [2] 
> http://www.postgresql.org/docs/9.2/static/functions-range.html#RANGE-OPERATORS-TABLE
>  
> [3] http://archives.postgresql.org/psycopg/2012-09/msg00051.php 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/shC1MhFZg4YJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: postgresql range types v2

[Simon Litchfield]

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 one: 
>
>
> https://github.com/mpaolini/django/commit/b754abdeab204949510500ccb1b845b7ad143542
>  
>
> copying here the rest of the original mail: 
>
> postgresql since version 9.2 added support for range types [1] 
> they have a nice set of specialized operators like "overlaps", "left of", 
> etc... [2] 
>
> So I decided to work on a reference implementation for Django 
> even if it looks like psycopg2 does not fully support yet these data types 
> [3] 
>
> The implementation is only a proof of concept and is not complete and not 
> tested 
> (but it does contain tests, of course!) 
>
> I did: 
>   - datetime range python data type: two bounds plus inclusive/excusive 
> info (very basic!) 
>   - datetime range model field 
>   - range specific lookups for querysets 
>   - non-overlapping constraint: db-level enforced with sql CONSTRAINT and 
> model validation 
>   - some documentation 
>
> TODO: 
>   - form, widget, modelform, localization, admin 
>   - more range types (int, bigint, etc...) 
>   - more validation against invalid ranges 
>   - better range type python implementation 
>   - more testing 
>
> Do you like it? Any chances for it to land in master once it is completed? 
> Or is it too specialized? 
>
> Cheers, 
>
> Marco 
>
> [1] http://www.postgresql.org/docs/9.2/static/rangetypes.html 
> [2] 
> http://www.postgresql.org/docs/9.2/static/functions-range.html#RANGE-OPERATORS-TABLE
>  
> [3] http://archives.postgresql.org/psycopg/2012-09/msg00051.php 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/EXxINLYk-hgJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Default project layout / directory structure

[Simon Litchfield]

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?
>
> Sure -- no disagreement that it would be good to have some common
> ground with regards to project layout. All we need now is to agree
> what that blessed project layout should be. :-)

Lowest common denominator is what we're after here I think. Eg --

manage.py
--conf
settings.py
settings_dev.py
--lib
other_app1
other_app2
--my_app1
--my_app2
--media
--templates
--templatetags (project tags, non-app specific, if you have any)
--views.py (project views, non-app specific, if you have any)
--urls.py (project urls, non-app specific)

Or maybe this --

manage.py
--conf
settings.py
settings_dev.py
(wsgi files)
--lib
other_app1
other_app2
--project
my_app1
my_app2
templatetags (project tags, non-app specific, if you have any)
views.py (project views, non-app specific, if you have any)
urls.py (project urls, non-app specific)
--media
css
img
js
uploads
--templates

This way we keep our pythons separate from our chickens.

Also to suggest a preferred media structure or not- at least a
centralised uploads / var media folder would be good practice I think,
at least from provisioning and permissions etc point of view.

Thoughts? These are just a few suggestions to get the conversation
started!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Default project layout / directory structure

[Simon Litchfield]

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 -- each have their own way, what a waste, not DRY.

3. The new breed of django hosting platforms that are on their way -- gives 
them something to base their tools on.

Why not have a standard way, standard tools, etc etc- built in, batteries 
included. DRY.

Whether it be a plain old manage.py-friendly directory layout, something 
virtualenv+pip powered, maybe something like Lincoln Loop's startproject style, 
Eric Holscher's, or whatever. Lets not go too nuts on directories though, they 
get tiring (especially in textmate)

Thoughts?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Custom FilterSpecs

[Simon Litchfield]

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 because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Permission support for admin inlines

[Simon Litchfield]

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 obvious; has_add would result in no add form; has_delete
in no delete tick box; and for has_change, showing as readonly_fields
would probably be easiest.

Any thoughts?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Error email flooding on high traffic production sites

[Simon Litchfield]

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 included" and "production ready" ethos in mind, I
reckon this needs fixing.

1) Max emails per minute setting

2) Include alternative error handler middleware in core

I haven't tried it yet, but this looks interesting (note web2py
includes this) --
http://bitbucket.org/ashcrow/django-error-capture-middleware/wiki/Home

Thoughts? I know I'm not the only one who has run into this (Russ?)

Cheers
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: MySQL index hints

[Simon Litchfield]

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 - with_hints(use={}, force={}, ignore={})
Oracle - with_hints(index={}, ...)

That gives plenty of name space to breathe in.

Next --

> Using the filter/exclude name sounds interesting, but skips the first
> step of putting an index hint on the origin table. For example,
> Book.objects.filter(author__name='foo') -- now put an index hint on
> Book; now put one on Author. If Author and Book are an a m2m relation
> -- put a hint on the m2m table.

How about --

  {'book': 'book_idx', 'author': 'author_idx', 'author__name':
'm2m_idx'}

Or, if you want to cover absolutely every possibility --

  {'book': 'book_idx', 'author__name__author': 'author_idx',
'author__name': 'm2m_idx'}

That is, require indexes on the right side of joins to be named
explicitly, just in case Author is used in another join.

Sounds complicated, but obviously edge case. Common usage will be
simple, eg {'book':'book_idx'}.

Let me know what you think.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: MySQL index hints

[Simon Litchfield]

> 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 enthusiasm about this specific feature (as proposed).
> I've spent enough time in the past covering for the inadequacies of
> MySQL. I don't particularly relish the thought of adding more time to
> that particular ledger. :-)

I know, I've seen you pulling your hair out :-)

> Having an implementation ignore kwargs is the obvious approach to
> providing this feature cross platform. The issue for me is what
> exactly the kwargs should be, and how they would be interpreted. It
> isn't clear to be how 'index="my_index"' maps to the application of
> USE INDEX, IGNORE INDEX or FORCE INDEX in a query, or how the
> dictionary syntax would map to the situation where you have two
> appearances of a given table in a query.

Great, so lets define the syntax then and away we go.

1) I'd say index= would map to MySQL's USE INDEX and Oracle's index().
The others you mention there would be MySQL-specific kwargs. Or, more
simply, ignore and force could be '-index' and '+index'. Bit like we
use + and - for order_by.

2) The multiple table issue is edge case but worth supporting if it
doesn't complicate the syntax too much. Rather than use models as keys
we could use the filter/exclude name; eg {'relatedmodel__field':
'index'} would apply 'index' specifically to the 'relatedmodel__field'
join.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: MySQL index hints

[Simon Litchfield]

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 BOOLEAN MODE);
> Seems to be very MySQL specific...

Yes Henrik, it's true- this is a classic example of a *very useful*
MySQL-specific feature already in the ORM.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: MySQL index hints

[Simon Litchfield]

> 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 are easy.
Re 4 though, every db does it differently. In practice, most don't
need hints like MySQL does , because their query optimisers do a
much better job.

I'd be happy to use raw(); but then you lose len(), slicing,
pagination, filter chaining, etc. My problem came about because admin
change lists were unusably slow on large tables. With_hints allowed a
simple monkey patch to admin, dropping 2s per page down to ~0.01s.

MySQL is still the most used backend AFAIK, and it's the one that
really needs the hints (poor old thing it is). Adding with_hints()
will only serve to encourage support from other backends too, where
possible.

Maybe we can make the with_hints() syntax more generic with both
common and backend-specific kwargs --

.with_hints(index='my_index')  (string implies index on queryset base
model)
.with_hints(index={Model:'my_index', RelatedModel:'index2'})
(dictionary allows defining index on a per-model basis)

So the Oracle backend, for example, could implement --

.with_hints(hash=True, index={Model:'my_index',
RelatedModel:'index2'})(

On Oracle there are dozens of possible hints, so I'd say unsupported
kwargs could simply be ignored. This would ensure seamless database
portability.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

MySQL index hints

[Simon Litchfield]

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 because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Ticket 9360 get_fieldsets doesn't work as advertised

[Simon Litchfield]

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 of fields
(eg, based on request permissions), then save using all
declared_fields thereby wiping your own data???

IMHO, get_fieldsets doesn't work as advertised. The patch is pretty
obvious, but I don't want to get in trouble again for reopening the
ticket :-) ..
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Silencing TemplateSyntaxError

[Simon Litchfield]

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 site down and wondering what the hell happened
(especially if DEBUG=False like it usually would be in production)
- They could be left alone to do the templating and bug the Django
guys less, because errors wouldn't halt their work.

The idea for the templating system was to keep it simple enough for
non Python coders, right?


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

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

[Simon Litchfield]

+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 Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Static vs variable test fixtures

[Simon Litchfield]

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 of fixtures that only need to be loaded at the
start of the TestCase.

I've run into this problem a few times now and this simple improvement
would make tests so much nicer :-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Reload method for models

[Simon Litchfield]

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, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Reload method for models

[Simon Litchfield]

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
to reload.

Only way around this I propose is some kind of .reload() method. We
can't openly endorse using raw SQL alongside the caching ORM and not
have one.

See ticket for background, and a possible patch --
http://code.djangoproject.com/ticket/901
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Newforms DateField/DateTimeField initial value rendering

[Simon Litchfield]

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?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Newforms DateField/DateTimeField initial value rendering

[Simon Litchfield]

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

INPUT_FORMATS_DMY = ..
...
field = forms.DateTimeField(widget=forms.DateTimeInput(format='...'),
input_formats=INPUT_FORMATS_DMY)

Then add the extra code to every occurance of a date/datetime field to
all our Forms and ModelForms.

Tad ugly though, don't you think? Most platforms/languages/frameworks
handle the MDY/DMY situation relatively elegantly using some kind of
setting.

Am I not the only non-US guy who sees this as a major shortcoming in
newforms?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

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

[Simon Litchfield]

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 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Newforms DateField/DateTimeField initial value rendering

[Simon Litchfield]

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 can do better than force new users
outside US to scratch around contribs to find a half-baked solution to
their trivial date formatting problem, and/or write their own fields.

How about a new setting? Maybe we could even use TIME_ZONE?

Thoughts? More than happy to submit the patch.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Add newform errors directly (without using ValidationError)

[Simon Litchfield]

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
simple form field validation, but not for more involved post-
processing of forms. This forces us to resort to one of three ugly
solutions -- a) hacking them into the form errorlist; or b) duplicate
and create an additional passage of returned errors when a perfectly
good one exists already; or c) over-complicate by moving post-
processing code that belongs in the view into the form.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

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

[Simon Litchfield]

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
> 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 changed.
>
> We could also easily decide if/when we need to update related models,
> in our app save() hooks, etc.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Models to keep a copy of their last saved values?

[Simon Litchfield]

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

We could also easily decide if/when we need to update related models,
in our app save() hooks, etc.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Another urlpatterns proposal (add method column)

[Simon Litchfield]

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, POST, HEAD, etc.


On Oct 2, 10:53 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> On 10/2/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> > That said, I think there are probably others out there like you who
> > would want this, and there's actually nothing stopping you from
> > releasing it as a separate app, or even a snippet.
>
> Well, looks like I misspoke. It seems the URL resolver is only given
> the path, as opposed to the whole request object, so it would require
> a bit more hacking than I originally thought. It might still be
> possible without changing any Django internals, but you'd have to
> touch more than you should, and it wouldn't be pretty. I wouldn't
> recommend it, so consider that whole idea withdrawn. Sorry about not
> looking at the code before I typed.
>
> -Gul


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Looking for discussion on #5535

[Simon Litchfield]

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 said the following:
> > 1. It breaks consistency with how we currently do things
>
> I still disagree with you there. It would only break consistency if it
> was actually crossing the relation and checking the ID field of the
> other table.
>
> Since it is *not* a cross-relation lookup, not using __ syntax is *not*
> inconsistent. On the contrary, it now becomes *more* consistent with
> normal data access, such as obj.fkey_id
>
> > 2. What happens if somebody actually has a non-foreign-key field whose
> > name ends with the sequence "_id"?
>
> Then it finds that field as normal, and everything continues on. You'd
> only have to fallback to attname if you don't find a matching field name.
>
> --
> Collin Grady
>
> "Life is too important to take seriously."
>   -- Corky Siegel


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Looking for discussion on #5535

[Simon Litchfield]

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 an int, a str, or a model instance to
> the foreign key field).

Hmmm, I'd almost say this was the best solution; ie, losing the magic
fkname_id notation altogether in favour of making it consistent (in a
gradual phased manner of course!).

The only problem here though, we'd need to continue the trend, by
changing model.__set__ so that by setting instance.fkname = 47 it'd
lazy load instance.fkname as a proper model instance, rather than an
int (or str/date/time etc).

Great, but then how do I get the fkname_id int without having to hit
the database? Looks like we're straight back to the drawing board with
the magic fkname_id notation again!


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Looking for discussion on #5535

[Simon Litchfield]

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 nutshell. Empty your head of Django for a
second, have another look; do you not see the inconsistency there?

Why confuse the issue? Foreign keys are always named fieldname_id by
default, regardless of the foreign table's primary key field name. So,
the argument about readability, and confusing foo_bar with foo__bar is
unfounded. It's always gonna be foo__bar for foreign key, and foo_bar
for the local field. Moreover, foo__id and foo_id are the same value
anyway.

And perhaps more importantly, both of these .get* examples here
generate an unnecessary join anyway.

Bottom line is, surely any ORM should allow you to perform a simple
single table lookup based on *any* field in the given table?


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Time for a new release?

[Simon Litchfield]

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;
> 2) The current trunk seems to be in pretty good condition, and Malcolm
> is about to land a big refactor of query.py which could lead to some
> temporary instability;
> 3) Malcolm has hinted that he has a stash of backwards incompatible
> changes that he has been queuing up to make in one big hit prior to a
> release (If I have misunderstood you here, Malcolm, I apologise)
>
> However, most importantly:
>
> 4) The max_length issue is starting to get ridiculous. So far, the
> running ticket count is: 5254, 5252, 5240, 5210, 5208, 5194, 5184,
> 5162, 5159, 5144, 5119, 5117. For every user that has gone to the
> trouble to post a ticket, there is probably a whole lot more that have
> tried, failed, and said "Perfectionists with deadlines? Rubbish! Can't
> even get their tutorials right!"
>
> Newforms-admin is still a little bit off being able to land, so the
> previously announced schedule for the deprecation of oldforms would
> probably need to be pushed back by a release.
>
> However I don't see any other way to kill the max_length problem. One
> the one hand, the max_length problem is is an RTFM issue - but on the
> other hand, if multiple users keep making the the same error over and
> over again, there comes a point at which you have to question whether
> the documentation is really the problem.
>
> Comments?
>
> Yours,
> Russ Magee %-)


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---