Re: A shortcut for django.core.urlresolvers.reverse

[Matt]

On 18 Apr, 23:05, SmileyChris <[EMAIL PROTECTED]> wrote:
> I'm not sure this is really adding that much. Why can't you just use
> reverse as it stands? It doesn't seem hard to do:
> >>> some_id = 1
> >>> reverse(some_view, kwargs=dict(id=some_id))
> '/event/1/'
> or:
> >>> reverse(some_view, args=[some_id])
> '/event/1/'

Yeah, that works just fine.  But a shortcut feels a little nicer.
Just as I prefer:

return render_to_response(template_name, context,
RequestContext(request))

to:

return HttpResponse(loader.render_to_string(template_name,
context,
RequestContext(request)))

M.

--
Matt Riggott (mailto:[EMAIL PROTECTED]).
Dictated but not read.


--~--~-~--~~~---~--~~
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: "selected" for ForeignKey field?

[Matt]

I know where the problem is, and have a work-around but it isn't all
that pretty.  The problem is here:

class FormWrapper:
...
def __getitem__(self, key):
for field in self.manipulator.fields:
if field.field_name == key:
if hasattr(field, 'requires_data_list') and
hasattr(self.data, 'getlist'):
data = self.data.getlist(field.field_name)
else:
data = self.data.get(field.field_name, None)
if data is None:
data = ''
return FormFieldWrapper(field, data,
self.error_dict.get(field.field_name, []))
raise KeyError

the ForeignKey field, "division" in your example, will be the
field.field_name, but the real data we want is "division_id".

as a workaround, I've inserted the following just before "if data is
None":

if data is None:
data = self.data.get('%s_id' % field.field_name,
None)

Ugly, but does the right thing.  Can someone shed light on why this is
needed?

Thanks.

- matt

Pedro Furtado wrote:
> I am having the same problem here and can't find a solution for it. At
> formfields.py the following code doesn't seems to work cause str_data looks
> empty:
>
> if str(value) == str_data:
> ' selected="selected"'
>
> As I'm not a great developer some newbye mistake may exist in my template,
> but this thing was getting me crazy so I tried to verify the code looking
> for the error.
>
> Pedro FUrtado
>
> 2005/8/31, HBTaylor <[EMAIL PROTECTED]>:
> >
> >
> > I posted this on Djangu Users, but Django Developers may be a better
> > place.
> >
> > I have a model with the following (exerpt):
> >
> > class Team(meta.Model):
> > name = meta.CharField(maxlength=200)
> > venue = meta.CharField(maxlength=200)
> > division = meta.ForeignKey(Division)
> > # snip snip snip
> >
> > class Division(meta.Model):
> > name = meta.CharField(maxlength=40)
> > conference = meta.ForeignKey(Conference)
> > # snip snip snip
> >
> > I am using the update_object generic view to present the update form
> > for an existing Team. It has {{ form.name <http://form.name> }}, {{
> > form.venue }}, and {{
> > form.division }} in the form template. The view correctly creates a
> > "select" for the division, but the "selected" value is the first one
> > ("-") instead of the correct one already set (and validated in
> > the DB) for the team's division.
> >
> > Is there some attribute/parameter I can add to {{ form.division }} to
> > make it correctly select the existing value? It seems this should be
> > the default, but I couldn't find a generic views example which
> > contained a SELECT (for a hard-coded set of choices or for a foreign
> > key situation). If one exists and I just didn't find it, I apologize.
> > 
> > Thanks for any light which can be shed.
> > 
> > H.B.
> > 
> >

timesince filter and months

[Matt]

The handy timesince filter, django.utils.timesince.timesince(d), uses
30 days to represent all months.  This leads to funny results when
dealing with large timespans.  For example, my daughter was born on
March 9th of this year and timesince says she is 7 months old today,
instead of on the 9th.

I guess this is just supposed to be a fuzzy representation, but does
anyone have ideas on a change to take actual months into account?

Thanks.

- matt

Make DATABASES[x]['TEST']['USER'], etc available for non-Oracle DBs

[matt]

Currently, the TEST database settings like USER and PASSWORD are only used 
by the Oracle backend. 

See: 
https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-TEST_USER

I just hit a case where it would be nice to use a different database user 
during testing -- and I don't use Oracle. I know there are workarounds, but 
since Django already provides an elegant way to solve the problem (for one 
backend), why not do it for the others?

I'd be happy to contribute a patch, but I'm curious if that feature was 
left out of the other backends for a reason.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/498eb856-4732-4d10-aa79-01800fa6d461%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DjangoCon

[Matt]

On Jul 18, 1:21 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> When the time comes there will be a large and loud public announcement
> that you will not be able to miss.

Somehow when those large and loud public announcements happen I seem
to get them about 10 minutes after everyone else.



--~--~-~--~~~---~--~~
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: DEPs: Django Enhancement Proposals

[Matt]

And DEP20 for Django philosophy :}

https://docs.djangoproject.com/en/dev/misc/design-philosophies/

-- 
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/5602f366-9b75-4393-9dab-382e7d6edd8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support byte range requests in django.views.static.serve

[matt]

Here is the commit for adding HTTP range support. I tested it in late 
versions of Chrome, Firefox, Opera and IE.

https://github.com/satchamo/django/commit/2ce75c5c4bee2a858c0214d136bfcd351fcde11d

The RangedFileReader class may be superfluous but I'm not aware of anything 
in Django or the Python standard library that does something like that.

Feedback appreciated.

On Sunday, April 13, 2014 8:30:37 PM UTC-7, md...@pdx.edu wrote:
>
> Is the Django community interested in supporting HTTP range requests in 
> django.views.static.serve 
> ?
>
> The primary benefit I see is that it makes files served up for  and 
>  "seek-able" with the django server. This generally isn't a problem 
> for small files (except in Chrome 
> ), 
> but becomes an issue for larger ones.
>
> Werkzeug has a function that parses the range header 
> ,
>  
> which I used to support range requests in a Django application. I estimate 
> that robust support for HTTP range requests would cost <300 lines of code, 
> plus tests.
>

-- 
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/ce048851-9d85-4c94-a152-4e0bd617e815%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Races in sessions

[Matt]

The "post_comment" example of sessions appears to be incorrect: 
https://docs.djangoproject.com/en/3.1/topics/http/sessions/#examples

Imagine two HTTP requests coming in at the same time, both seeing that 
"has_commented" is False, and then both create a comment and set the 
session variable to True.

I just experienced this issue myself, which is why I bring it up.

I would offer to update the documentation...but I'm struggling to come up 
with a way to actually make this pattern work with sessions! Assuming there 
are other views that update other variables in the session, it seems like 
you must lock the session when you read it (i.e. "SELECT...FOR UPDATE"). So 
anything that reads or writes to the session must be wrapped in an atomic 
block.

I think it might be useful to add a method to support locking the session 
before any reads/writes. Or maybe we should just update the docs to warn 
people about how race prone sessions are?

Any thoughts?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/89941f4b-61a2-446e-ba72-dfe428e0a9dbn%40googlegroups.com.

Re: Races in sessions

[Matt]

Thinking out loud: You can't just lock the session when you think you have 
a critical section of code in a view because the session data is stored in 
one field in the database, and is *completely overwritten* on write. 
Consider this case:

Thread A: Read session data
Thread B: Open transaction, read session (with lock) data, add 
session['foo'] = 1, write session back to database, close transaction.
Thread A: session['bar'] = 1, save session (completely overwriting Thread 
B's changes so 'foo' doesn't exist anymore)

So any view that will write to the session *must* lock it before reading. 
And like Stephen is saying, you don't want to do that on every request. I 
suppose you could keep session reads as-is. But any time you need to do a 
write, you must explicitly wrap it in a transaction, and refresh the data 
from the database (while locking other writers):

...
# freely read any session data (but it could be stale)
...
# now we need to write something to the session
with transaction.atomic():
# the session data needs to be refresh if it was updated by another 
transaction after it was first read by this thread
request.session.lock_and_refresh()
if request.session.get('has_commented', False):
request.session['has_commented'] = True
...
request.session.save()

Session implementations could provide a context manager (if they support 
atomic writes) so it's not so ugly:

with request.session.atomic():
if request.session.get("has_commented", False):
request.session['has_commented'] = True
...

But EVERY session write must follow that pattern, or it's all for naught. I 
don't think Django core uses sessions much, so updating core doesn't sound 
bad. It's *everyone *downstream. That seems totally impractical. I do think 
there are some *very *subtle bugs that would be resolved by adopting 
something like this. But it may not be worth the trouble.


On Sunday, February 7, 2021 at 11:13:51 AM UTC-8 Adam Johnson wrote:

> Stephen - you're right that a constraint is the best way to enforce 
> consistency in the DB. That doesn't fit every use case for sessions though 
> - people use Django's built-ins with many different kinds of data stores 
> that don't support locking or constraint semantics, such as remote API's.
>
> Matt - I think we could remove that example.
>
> As for a new session locking method, I'm not sure how feasible it is *in 
> general* since the session API is designed to back onto any kind of data 
> store. If you had an example implementation it would be good to see and 
> know how well it performs in a real world setting.
>
> On Sun, 7 Feb 2021 at 18:58, Stephen J. Butler  
> wrote:
>
>> The way I'd solve this example is to create a unique constraint/index in 
>> the DB. The session check gives a quick pre-check, but in the event of a 
>> race the DB enforces absolute consistency.
>>
>> If the constraint isn't possible or is too complex, then your "SELECT... 
>> FOR UPDATE" belongs on the check for whether someone is allowed to comment, 
>> not on the session. Select for update is a kind of locking, and the rule 
>> for locking is to do it as little as possible, in as isolated section of 
>> code as possible. So you do it around the code that checks if a user can 
>> create a comment and then creates it (which will probably be a small 
>> percent of your requests) vs. doing it in the session logic which gets run 
>> for 100% of requests (but is unneeded 99.99% of the time).
>>
>> On Sun, Feb 7, 2021 at 12:08 PM Matt  wrote:
>>
>>> The "post_comment" example of sessions appears to be incorrect: 
>>> https://docs.djangoproject.com/en/3.1/topics/http/sessions/#examples
>>>
>>> Imagine two HTTP requests coming in at the same time, both seeing that 
>>> "has_commented" is False, and then both create a comment and set the 
>>> session variable to True.
>>>
>>> I just experienced this issue myself, which is why I bring it up.
>>>
>>> I would offer to update the documentation...but I'm struggling to come 
>>> up with a way to actually make this pattern work with sessions! Assuming 
>>> there are other views that update other variables in the session, it seems 
>>> like you must lock the session when you read it (i.e. "SELECT...FOR 
>>> UPDATE"). So anything that reads or writes to the session must be wrapped 
>>> in an atomic block.
>>>
>>> I think it might be useful to add a method to support locking the 
>>> session before any reads/writes. Or maybe we should

Stop QuerySet repr from executing queries

[Matt]

repr(some_queryset) will execute the query and display some results from 
the query. This is done because it's (somewhat) helpful for debugging.

https://github.com/django/django/blob/2a6f45e08e8cb8c7e5157915c378b453109424d2/django/db/models/query.py#L248

This has caused at least two people to scratch their heads about odd 
queries being generated, and it crashed my production database yesterday.

See #20393  and #30863 


Luke Plant has said:

... you have a conflict between the goal of being information rich and with 
> *always* being useful for debugging. In general, automatically seeing the 
> results is information rich and is useful in debugging, but sometimes it 
> causes further problems.
>
> I have thought about it, and with this conflict of goals, I think we are 
> going to have to err on the side of the current behaviour. It is possible 
> to work around by not calling repr on QuerySets in your middleware, and 
> there are too many people who will be upset (or have problems with their 
> own debugging facilities) by changing this.
>

One reason people love Django is because of its attention to things like 
debug-ability. I can certainly see the argument here. However, I want to 
press on the desirability of this feature.

The argument that you can work around it by not calling repr is certainly 
true, but in practice, I don't think it's reasonable. Production error 
reporting tools (like Sentry and New Relic) will call repr when reporting 
on exceptions.

I see this behavior as being analogous to a file object printing the first 
21 characters of a file, which it doesn't do (for good reason, I would 
imagine):

>>> f = open("foo.py")
>>> repr(f)
"<_io.TextIOWrapper name='foo.py' mode='r' encoding='UTF-8'>"
>>>

I think we ought to reconsider the behavior of repr on QuerySets. I'm of 
the opinion that we should scrap it completely. It could be replaced by 
something that generates the SQL that would be executed (although that may 
be tricky), or some kind of representation of the query filter. 

Any thoughts?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/29051be5-2988-4295-a8d9-1c5ae9555ee1%40googlegroups.com.

Re: Stop QuerySet repr from executing queries

[Matt]

 

I reviewed the patch that was originally created for this:

 

https://github.com/django/django/pull/1055/commits/7d53d428c0323a7eca93b7b56968a895b031e2ae

 

Essentially, it only includes the results of the queryset in the repr *if* 
the QuerySet._result_cache has been populated. There is one minor thing I 
don't like about the particular implementation: it shows the empty list if 
the result cache is not populated. I think it should just show  
instead of . That way you can differentiate between 
_result_cache=None, and _result_cache=[].

 

This is an OK approach, but the inconsistency in the representation smells 
a little off.

 

RawQuerySet simply does:

 

def __repr__(self):

return "<%s: %s>" % (self.__class__.__name__, self.query)

 

which is dead simple, and useful. I think it can be argued that QuerySet 
should be consistent with it (otherwise, why isn't RawQuerySet executing 
its SQL to show the repr?)

 

Regarding other things that have been mentioned: I'm not too keen about 
introducing a setting for this behavior, or doing things differently in an 
interactive console. Django already has a lot of settings, and this seems 
like such a minor thing. And I don't know of any precedent for changing the 
behavior of Django in an interactive shell (and you can tell I'm not a fan 
of inconsistent behaviors).


I'm going to re-open the ticket and hope other Django devs chime in.



On Thursday, October 10, 2019 at 8:50:31 AM UTC-7, Matt wrote:
>
> repr(some_queryset) will execute the query and display some results from 
> the query. This is done because it's (somewhat) helpful for debugging.
>
>
> https://github.com/django/django/blob/2a6f45e08e8cb8c7e5157915c378b453109424d2/django/db/models/query.py#L248
>
> This has caused at least two people to scratch their heads about odd 
> queries being generated, and it crashed my production database yesterday.
>
> See #20393 <https://code.djangoproject.com/ticket/20393> and #30863 
> <https://code.djangoproject.com/ticket/30863>
>
> Luke Plant has said:
>
> ... you have a conflict between the goal of being information rich and 
>> with *always* being useful for debugging. In general, automatically 
>> seeing the results is information rich and is useful in debugging, but 
>> sometimes it causes further problems.
>>
>> I have thought about it, and with this conflict of goals, I think we are 
>> going to have to err on the side of the current behaviour. It is possible 
>> to work around by not calling repr on QuerySets in your middleware, and 
>> there are too many people who will be upset (or have problems with their 
>> own debugging facilities) by changing this.
>>
>
> One reason people love Django is because of its attention to things like 
> debug-ability. I can certainly see the argument here. However, I want to 
> press on the desirability of this feature.
>
> The argument that you can work around it by not calling repr is certainly 
> true, but in practice, I don't think it's reasonable. Production error 
> reporting tools (like Sentry and New Relic) will call repr when reporting 
> on exceptions.
>
> I see this behavior as being analogous to a file object printing the first 
> 21 characters of a file, which it doesn't do (for good reason, I would 
> imagine):
>
> >>> f = open("foo.py")
> >>> repr(f)
> "<_io.TextIOWrapper name='foo.py' mode='r' encoding='UTF-8'>"
> >>>
>
> I think we ought to reconsider the behavior of repr on QuerySets. I'm of 
> the opinion that we should scrap it completely. It could be replaced by 
> something that generates the SQL that would be executed (although that may 
> be tricky), or some kind of representation of the query filter. 
>
> Any thoughts?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ddce11f2-6971-484c-a9bf-28f65421488f%40googlegroups.com.

Re: Stop QuerySet repr from executing queries

[Matt]

Created https://github.com/django/django/pull/11917

This patch will print the results of the query (if it has been evaluated). 
I did hit one odd case while writing the tests. Essentially, if you do:

queryset = SomeModel.objects.all()
list(queryset)
SomeModel.objects.create(...)
repr(queryset)

The newly created model won't appear in the repr. I believe the existing 
behavior will show the newly created object. I'm still not a huge fan of 
this repr behavior (I lean towards just displaying the SQL like 
RawQuerySet).

I just noticed felixxm closed the original ticket. Unfortunately, I don't 
think I'm advertising the severity of this issue very well and most people 
are probably never going to encounter it (and if they do, it's probably 
their own fault). So to be more explicit about the problem...

*How to crash your production database with Django:*

   1. Use an error reporting system like Sentry
   2. Have a database table with millions of rows (the more the "better")
   3. Have a Django model representing the above table, with a default sort 
   of a non-indexed field
   4. Have a local variable somewhere in the stack like `queryset = 
   HugeTable.objects.all()` (assume it doesn't get "refined down" until deeper 
   in your code)
   5. Trigger an uncaught exception
   6. Your error reporting layer will call repr() on that queryset local 
   variable.
   7. repr(queryset) will trigger your database server to do SELECT ... 
   FROM HugeTable ORDER BY NonIndexedColumn LIMIT 21 (locking it up)
   8. Bonus: Trigger all of the above on all your wsgi processes
   
In short, just call repr(BigTable.objects.all()) (where BigTable has an 
ordering on an non-indexed column and lots of rows)



On Thursday, October 10, 2019 at 8:50:31 AM UTC-7, Matt wrote:
>
> repr(some_queryset) will execute the query and display some results from 
> the query. This is done because it's (somewhat) helpful for debugging.
>
>
> https://github.com/django/django/blob/2a6f45e08e8cb8c7e5157915c378b453109424d2/django/db/models/query.py#L248
>
> This has caused at least two people to scratch their heads about odd 
> queries being generated, and it crashed my production database yesterday.
>
> See #20393 <https://code.djangoproject.com/ticket/20393> and #30863 
> <https://code.djangoproject.com/ticket/30863>
>
> Luke Plant has said:
>
> ... you have a conflict between the goal of being information rich and 
>> with *always* being useful for debugging. In general, automatically 
>> seeing the results is information rich and is useful in debugging, but 
>> sometimes it causes further problems.
>>
>> I have thought about it, and with this conflict of goals, I think we are 
>> going to have to err on the side of the current behaviour. It is possible 
>> to work around by not calling repr on QuerySets in your middleware, and 
>> there are too many people who will be upset (or have problems with their 
>> own debugging facilities) by changing this.
>>
>
> One reason people love Django is because of its attention to things like 
> debug-ability. I can certainly see the argument here. However, I want to 
> press on the desirability of this feature.
>
> The argument that you can work around it by not calling repr is certainly 
> true, but in practice, I don't think it's reasonable. Production error 
> reporting tools (like Sentry and New Relic) will call repr when reporting 
> on exceptions.
>
> I see this behavior as being analogous to a file object printing the first 
> 21 characters of a file, which it doesn't do (for good reason, I would 
> imagine):
>
> >>> f = open("foo.py")
> >>> repr(f)
> "<_io.TextIOWrapper name='foo.py' mode='r' encoding='UTF-8'>"
> >>>
>
> I think we ought to reconsider the behavior of repr on QuerySets. I'm of 
> the opinion that we should scrap it completely. It could be replaced by 
> something that generates the SQL that would be executed (although that may 
> be tricky), or some kind of representation of the query filter. 
>
> Any thoughts?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fef2d187-196c-43cc-8935-8b0f4779d727%40googlegroups.com.

Re: Stop QuerySet repr from executing queries

[Matt]

Perhaps we ought to just keep the current behavior when DEBUG is True (it 
seems so obvious now, I can't believe it wasn't the first thing I 
suggested)? Django does lots of helpful things in DEBUG mode at the expense 
of performance. I think this would be an innocuous change for most people. 

It is not the most important thing to remove behavior that most of users 
> use because we want to fix an edge case that was reported twice in the last 
> six years.
>

I don't consider any of those *individual *conditions to trigger the 
problem "off the beaten path" for a bigger production Django site. All of 
them *combined *is obviously extremely rare, but it will effect someone 
else eventually*. *It doesn't sit well with me to not fix the issue. Django 
should be reliable in production for any combination of those conditions.

On Wednesday, October 16, 2019 at 12:14:37 AM UTC-7, Mariusz Felisiak wrote:
>
> W dniu środa, 16 października 2019 07:53:05 UTC+2 użytkownik Harro napisał:
>>
>> Yes, it's a complicated issue, but isn't the SQL query the ultimate 
>> representation of which methods are called or not?
>>
>> Having the query evaluated during debugging has been shown to be harmful 
>> in certain situations, isn't that the most important thing to fix?
>>
>
> Current behavior is extremely valuable IMO. It is not the most important 
> thing to remove behavior that most of users use because we want to fix an 
> edge case that was reported twice in the last six years. I agree that we 
> can clarify this in docs. SQL query is not a solutions because not all of 
> ORM users know SQL. Moreover the current `repr()` shows values from DB that 
> we'll miss showing only SQL. You can check in the Django documentation how 
> users use the current `repr()` e.g. in tutorials.
>
> Best,
> Mariusz
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/689bd01d-a949-4e65-9cac-357fefa56680%40googlegroups.com.

Using auth stuff without installing the auth app

[Matt]

I like to use the authentication machinery in Django, without explicitly 
putting 'django.contrib.auth' in INSTALLED_APPS. This prevents a bunch of 
unused tables from being creating in the database.

This was possible in earlier version of Django. In 1.8, a spurious warning 
was generated, but that was fixed in #24564 
(https://groups.google.com/forum/#!searchin/django-developers/$2324564/django-developers/7b4xzkjLFH8/wLJ83Bxa_h4J)

In Django 1.9, it doesn't seem possible anymore (see traceback). Using the 
auth stuff without installing the app -- is that something we want to 
support or not?

Traceback (most recent call last):
  File "/usr/lib/python3.4/wsgiref/handlers.py", line 137, in run
self.result = application(self.environ, self.start_response)
  File 
"/home/example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/contrib/staticfiles/handlers.py",
 
line 63, in __call__
return self.application(environ, start_response)
  File 
"/home/example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/core/handlers/wsgi.py",
 
line 158, in __call__
self.load_middleware()
  File 
"/home/example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/core/handlers/base.py",
 
line 51, in load_middleware
mw_class = import_string(middleware_path)
  File 
"/home/example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/utils/module_loading.py",
 
line 20, in import_string
module = import_module(module_path)
  File "/usr/lib/python3.4/importlib/__init__.py", line 109, in 
import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 2231, in _gcd_import
  File "", line 2214, in _find_and_load
  File "", line 2203, in 
_find_and_load_unlocked
  File "", line 1200, in _load_unlocked
  File "", line 1129, in _exec
  File "", line 1448, in exec_module
  File "", line 321, in 
_call_with_frames_removed
  File 
"/home/example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/contrib/auth/middleware.py",
 
line 3, in 
from django.contrib.auth.backends import RemoteUserBackend
  File 
"/home/example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/contrib/auth/backends.py",
 
line 4, in 
from django.contrib.auth.models import Permission
  File 
"/home/example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/contrib/auth/models.py",
 
line 38, in 
class Permission(models.Model):
  File 
"/home/example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/db/models/base.py",
 
line 102, in __new__
"INSTALLED_APPS." % (module, name)
RuntimeError: Model class django.contrib.auth.models.Permission doesn't 
declare an explicit app_label and isn't in an application in INSTALLED_APPS.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/839b75d4-c32a-404e-b991-0315804f095b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using auth stuff without installing the auth app

[Matt]

I created https://code.djangoproject.com/ticket/26401

> Since the usage of any of the backends requires models

I used the ModelBackend with no issues in Django 1.8 (without auth in 
INSTALLED_APPS). So that is the place I want to refactor.


I'm trying to write a regression test for this, but I can't think of a good 
way to do it. Essentially, I want to ensure 
django.contrib.auth.context_processors/middleware/backends can be imported 
if django.contrib.auth is not in INSTALLED_APPS. Using 
`override_settings(INSTALLED_APPS...)` doesn't "undo" the imports, so 
importing the modules again won't trigger an exception. Any ideas?

On Wednesday, March 23, 2016 at 1:49:32 AM UTC-7, Florian Apolloner wrote:
>
> Oh yes, this is a bug. We should ensure that RemoteUser backend is 
> imported in the middleware itself or that backends.py does not trigger any 
> model imports. Since the usage of any of the backends requires models, the 
> import there seems fine -- I'd import RemoteUserBackend in 
> RemoteUserMiddleware.__init__ -- A patch would be very welcome.
>
> Cheers,
> Florian
>
> On Wednesday, March 23, 2016 at 1:57:41 AM UTC+1, Matt wrote:
>>
>> I like to use the authentication machinery in Django, without explicitly 
>> putting 'django.contrib.auth' in INSTALLED_APPS. This prevents a bunch 
>> of unused tables from being creating in the database.
>>
>> This was possible in earlier version of Django. In 1.8, a spurious 
>> warning was generated, but that was fixed in #24564 (
>> https://groups.google.com/forum/#!searchin/django-developers/$2324564/django-developers/7b4xzkjLFH8/wLJ83Bxa_h4J
>> )
>>
>> In Django 1.9, it doesn't seem possible anymore (see traceback). Using 
>> the auth stuff without installing the app -- is that something we want to 
>> support or not?
>>
>> Traceback (most recent call last):
>>   File "/usr/lib/python3.4/wsgiref/handlers.py", line 137, in run
>> self.result = application(self.environ, self.start_response)
>>   File "/home/
>> example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/contrib/staticfiles/handlers.py",
>>  
>> line 63, in __call__
>> return self.application(environ, start_response)
>>   File "/home/
>> example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/core/handlers/wsgi.py",
>>  
>> line 158, in __call__
>> self.load_middleware()
>>   File "/home/
>> example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/core/handlers/base.py",
>>  
>> line 51, in load_middleware
>> mw_class = import_string(middleware_path)
>>   File "/home/
>> example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/utils/module_loading.py",
>>  
>> line 20, in import_string
>> module = import_module(module_path)
>>   File "/usr/lib/python3.4/importlib/__init__.py", line 109, in 
>> import_module
>> return _bootstrap._gcd_import(name[level:], package, level)
>>   File "", line 2231, in _gcd_import
>>   File "", line 2214, in _find_and_load
>>   File "", line 2203, in 
>> _find_and_load_unlocked
>>   File "", line 1200, in _load_unlocked
>>   File "", line 1129, in _exec
>>   File "", line 1448, in exec_module
>>   File "", line 321, in 
>> _call_with_frames_removed
>>   File "/home/
>> example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/contrib/auth/middleware.py",
>>  
>> line 3, in 
>> from django.contrib.auth.backends import RemoteUserBackend
>>   File "/home/
>> example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/contrib/auth/backends.py",
>>  
>> line 4, in 
>> from django.contrib.auth.models import Permission
>>   File "/home/
>> example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/contrib/auth/models.py",
>>  
>> line 38, in 
>> class Permission(models.Model):
>>   File "/home/
>> example.com/.venv-bee4e82373367b8524982d09c561f7f1/lib/python3.4/site-packages/django/db/models/base.py",
>>  
>> line 102, in __new__
>> "INSTALLED_APPS." % (module, name)
>> RuntimeError: Model class django.contrib.auth.models.Permission doesn't 
>> declare an explicit app_label and isn't in an application in INSTALLED_APPS.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1f687f3e-e850-4a96-a1a6-5b878f2158ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using auth stuff without installing the auth app

[Matt]

>  the ModelBackend uses the Permission model, so why would that ever work 
without beeing in INSTALLED_APPS?

ModelBackend.authenticate() doesn't use the permissions models. And that's 
the method that gets used when authenticating a user. If I did something 
like `user.has_perm()`, things would blow up. But that is easy to override 
on your custom User class.

> the context_processor will break due to the AnonymousUser most likely

Hmm, right...I suppose AnonymousUser could be refactored into base_user.py.


On Wednesday, March 23, 2016 at 3:39:57 PM UTC-7, Florian Apolloner wrote:
>
>
>
> On Wednesday, March 23, 2016 at 8:36:39 PM UTC+1, Matt wrote:
>>
>> I created https://code.djangoproject.com/ticket/26401 
>> <https://www.google.com/url?q=https%3A%2F%2Fcode.djangoproject.com%2Fticket%2F26401&sa=D&sntz=1&usg=AFQjCNG7tek69HGtxC6RCZBQuW1ZQl5ZdA>
>>
>> > Since the usage of any of the backends requires models
>>
>> I used the ModelBackend with no issues in Django 1.8 (without auth in 
>> INSTALLED_APPS). So that is the place I want to refactor.
>>
>
> Mhm, that would surprise me -- the ModelBackend uses the Permission model, 
> so why would that ever work without beeing in INSTALLED_APPS? And as for 
> the ticket you generated, the context_processor will break due to the 
> AnonymousUser most likely -- this is not backend related.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/717f643a-b6a0-4e53-aa23-118623bc255b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using auth stuff without installing the auth app

[Matt]

First pass (still haven't figured out how to test it):
https://github.com/satchamo/django/commit/d5accc17122cd7486a5e5fd2d63b4c1f732a5c68

It's not obvious from the diff, but AnonymousUser depends on permission 
stuff (see AnonymousUser._get_groups/_get_user_permissions). On top of 
that, AnonymousUser.get_all_permissions/has_perm/has_module_perms now have 
function level imports. I'm tempted to move the 
_user_has_perm/_user_get_all_permissions/_user_has_module_perms 
helpers into base_user too.


On Wednesday, March 23, 2016 at 4:19:58 PM UTC-7, Florian Apolloner wrote:
>
>
>
> On Thursday, March 24, 2016 at 12:07:14 AM UTC+1, Matt wrote:
>>
>> >  the ModelBackend uses the Permission model, so why would that ever 
>> work without beeing in INSTALLED_APPS?
>>
>> ModelBackend.authenticate() doesn't use the permissions models. And 
>> that's the method that gets used when authenticating a user. If I did 
>> something like `user.has_perm()`, things would blow up. But that is easy to 
>> override on your custom User class.
>>
>
> Fair enough.
>  
>
>> > the context_processor will break due to the AnonymousUser most likely
>>
>> Hmm, right...I suppose AnonymousUser could be refactored into 
>> base_user.py.
>>
>
> Yes, but we should keep an import in models.py for compatibility.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2e68493e-93b7-4303-b733-20b9be2f344e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Let's schedule a Django sprint

[Matt]

On Sep 5, 9:32 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> I propose Friday, September 14.

Just a quick note for anyone in Scotland: there's a small group of us
(four at the mo) in Edinburgh joining the sprint from 7PM (GMT+1)
onwards.  We're meeting at my flat so if anyone in the area wants to
join us, email me for the address.

Cheers,
M.

--
Matt Riggott (mailto:[EMAIL PROTECTED]).
Dictated but not read.


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

Django on iPhone

[Matt]

Found a nice tutorial on how to install Django on your iPhone:
http://flickr.com/photos/skatterbean/1173984622/

Enjoy,

Matt Sterger


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

Check Constraints for databases that support them

[Matt Schinckel]

I'm very interested in the idea of expanding the database level
constraints that can be supplied to a database schema, and also
automatically apply the same constraints to the model/view in django.

The various backends that support them, I believe already apply such
constraints for PositiveIntegerField() and so on.

I would like to see the ability to define extra constraints as part of
the model definition, and have these applied in a similar manner to
the unique and unique_together constraints.

I am more familiar with PostgreSQL than anything else, but I believe
the syntax I am about to propose will work in several databases.

Check constraints can be divided into two types: column level and
table level.  With PostgreSQL, a column level constraint can reference
another column, but I would suggest that a constraint that does so
should be a table level constraint.

Column level constraints could be declared as a keyword argument to
the field constructor:

column = models.IntegerField(constraint='< 100')

Table level constraints could be declared as an attribute on the Meta
class of the model:

check_constraints = ('start < finish', )

Validation of the models should pick up when an incorrect constraint
has been declared. For instance, not using a valid operator ('# 100')
or not supplying a valid comparison value ('< 1e' for an IntegerField)
would be invalid column constraints, and comparing a Date to an
Integer would be an invalid table level constraint.

The code that should be generated would add "CHECK ('column' < 100)"
to the column definition in the first instance, and "CONSTRAINT
app_table_start_finish CHECK ('start' < 'finish')" to the table
definition in the second case.

I have already written code that fulfils these requirements, and some
tests for validation errors.  I have also written additions to
BaseModelForm which validates according to the defined constraint(s).

At this stage, I have not allowed for more complicated relationships,
such as ('first < second + 65'), but this is planned.

Is there anyone else interested in this?  Should I put this into a
ticket and attach my current diff?

--~--~-~--~~~---~--~~
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: Check Constraints for databases that support them

[Matt Schinckel]

On Sep 26, 10:27 pm, Tim Chase  wrote:
> > Is there anyone else interested in this?
>
> yes, I'd be interested in seeing some sort of database-level
> CHECK constraint as part of Django.  I had been sitting on my
> thoughts until I see the GSoC work done on model-validation wend
> its way towards trunk.  My hope had been to see model validation
> incorporate some DB-level CHECK constraints where feasible.

I did have a brief look at the django-check-constraint project on
google code, but it was overkill for what I needed.

> One of the other difficulties involves database expression
> differences.  For the simple cases such as you suggest, it's not
> as bad as they're fairly standard.  However, when functions are
> involved, each DB seems to have its own family of functions.
> E.g. if you want to assert the length of a string is 10
> characters ("len" vs. "strlen"?) or the time is during business
> hours ("hour(fieldname) between 8 and 17"...extracting
> time-portions varies across DB engines).

Yeah, for the time being I was only interested in simple cases.
Comparing against a static value in the case of column constraints,
and comparing two columns in the table-level case.  I don't even allow
for 'start < finish + 1' in the code I have written so far.

> I currently just add the CHECK constraints manually (well, in
> post-syncdb code).  Having them in a declarative fashion would
> help keep them in the right place.

Not to mention that it will allow the same code to control the db-
level constraint, and the django validation (admin, form).  Which is
DRY, and one of the reasons I am moving projects to django.

I also looked a little bit at south, which I have just started using
for migrations.  It doesn't have anything in there that is that
useful, other than raw SQL.  Which can do those type of things, but it
is nicer to move into the declaration.

Matt.
--~--~-~--~~~---~--~~
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: Adding signing (and signed cookies) to Django core

[Matt Brubeck]

On Sep 24, 10:18 am, Simon Willison  wrote:
> This offers two APIs: sign/unsign and dumps/loads. sign and unsign
> generate and append signatures to bytestrings and confirm that they
> have not been tampered with. dumps and loads can be used to create
> signed pickles of arbitrary Python objects.

Unpickling data sent by the client seems dangerous, since it can
execute arbitrary code on the server [1].  Obviously signing the data
goes a long way toward preventing such attacks, but I'm still not
comfortable with the idea that a leaked signing key could instantly be
escalated to arbitrary code execution. (For example, if the config
files are exposed through a misconfigured web server or accidentally
checked into public source control.) If you use JSON or some other
object serialization by default, then the damage from a leaked secret
key would be much more limited in most cases.

1. http://nadiana.com/python-pickle-insecure#HowtoMakeUnpicklingSafer

--~--~-~--~~~---~--~~
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: Adding signing (and signed cookies) to Django core

[Matt Brubeck]

On Oct 5, 1:44 pm, Simon Willison  wrote:
> Other than dates being a bit more annoying to pass around, I really
> don't think that telling people they can only dumps/loads JSON-
> encodable data would be a huge burden.

You could use YAML instead if you want date support... although JSON
does seem to have broader mind-share now.
--~--~-~--~~~---~--~~
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: Feature Request: Reinteract

[Matt Schinckel]

On Nov 27, 10:07 pm, noel  wrote:
> I really love this application Reinteract. Its an enhancement to
> Python Interactive Shell. And it would be lovely if I can use
> Reinteract with manage.py shell.

Have a look at bpython.  I have a command set up where I can run

./manage.py bshell

And I get a bpython shell with all of the models already imported.

--

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: why last_login in django.contrib.auth.models.User cannot be null?

[Matt Schinckel]

On Dec 15, 8:59 am, Sergiy Kuzmenko  wrote:
> I wonder if there is a particular reason why last_login field of  is not
> defined as "null=True"? It makes sense to me to have it as null which would
> mean that the user never logged in. Could there be any dependencies relying
> on this field not being null?

I came across one today:
contrib.auth.tokens.PasswordResetTokenGenerator
has a method _make_token_with_timestamp, which uses last_login to
create the
token. This means that if someone generates a password reset request,
the token
will be invalidated if that user then logs in. This could occur if a
person creates
password reset requests for a user that is not themself.

Matt.

--

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: why last_login in django.contrib.auth.models.User cannot be null?

[Matt Schinckel]

On Dec 15, 8:59 am, Sergiy Kuzmenko  wrote:
> I wonder if there is a particular reason why last_login field of  is not
> defined as "null=True"? It makes sense to me to have it as null which would
> mean that the user never logged in. Could there be any dependencies relying
> on this field not being null?
>

What isn't clear is that this value must be after 1900: I had used a
value of datetime(1,1,1,0,0) as "never logged in", but this fails with
password reset.

Matt.

--

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: dbsettings, and user configurable app settings

[Matt Boersma]

On Wed, Mar 10, 2010 at 7:51 AM, Brian Rosner  wrote:
>
> On Mar 10, 2010, at 7:16 AM, Joan Miller wrote:
>
>> It's a disaster from the maintenance view point. If it were not so,
>> then people would not be proposing to refactor the settings as has
>> been made in Pinax, or from multiple posts so many times.
>
> Like I mentioned in the post you made to the pinax-core-dev mailing list the 
> problem Pinax is trying to solve is *not* because the settings are written in 
> Python, but rather loading order and scope. Many projects quickly realize 
> that running a Django project with a single settings file is nearly 
> impossible with different environments all interacting with a single code 
> base. Some projects turn to importing a local_settings.py file which is what 
> Pinax currently does. This has worked wonderful for us for years.
> [snip]

The local_settings.py convention (thanks, Pinax!) has worked well for
us in an environment with multiple dev, test, and production server
tiers.  We solve the DATABASE_PASSWORD= issue by only allowing the
DBAs access to local_settings.py on production, and having an
svn:ignore rule that prevents anyone from accidentally checking it in
to version control.

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

Progressing #8901 "last_insert_id() for postgres fails when the autoincrement sequence name is too long"

[Matt Hoskins]

I think (from squinting at the code) that in Django 1.2 m2m field
updates now use the object save code to add relationships even where
there aren't specifically defined intermediate classes, whereas
previously the code did its own insert in such cases. So as a
consequence last_insert_id gets called as part of those m2m field
updates in cases where it previously didn't.

Because the table names for the m2m fields are generated from the
class name and the field name together there is scope for them to be
quite long and to hit the identifier limits and thus under postgresql
the sequence name auto-generated for the id will not confirm to what
the code currently guesses it to be (as per #8901) and so there'll be
an error on updating m2m fields with 1.2 and postgresql in cases where
there is a long enough field and class name and where it worked fine
in 1.1. I've hit this myself on updating to 1.2.

As #8901 hasn't been touched in a year (and has been sitting around
since 2008) I thought I'd have a look at it myself. I've not submitted
patches or tests for Django before, but I've had a stab at both for
#8901.

I'm not sure how to get this issue moved along closer to having a fix
incorporated - it could certainly do with someone more expert than me
in django and with postgresql knowledge reviewing my patch and tests
(I've not flagged the issue has "has tests" as I skipped adding a test
for one change for reasons I've noted on the issue, although maybe I
should flag it thus).

Regards,
Matt

-- 
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: Progressing #8901 "last_insert_id() for postgres fails when the autoincrement sequence name is too long"

[Matt Hoskins]

I haven't had a reply to this, which could have been bad timing
posting it around when the conference was happening, or it could be as
I gave the background first rather than summarising what I was after
first so people skipped over reading it :).

The ticket's languished for a couple of years now - I've submitted
what I think is a better patch on the ticket and included some tests
in the patch, but I've not previously done any work on Django before
and it could do with someone more versed in the postgresql back-end
for Django to take a look at it and advise me on how to get the ticket
moved along (and whether my tests are sufficient and in a good enough
place in the test suite).

Regards,
Matt


On May 25, 12:00 pm, Matt Hoskins  wrote:
> I think (from squinting at the code) that in Django 1.2 m2m field
> updates now use the object save code to add relationships even where
> there aren't specifically defined intermediate classes, whereas
> previously the code did its own insert in such cases. So as a
> consequence last_insert_id gets called as part of those m2m field
> updates in cases where it previously didn't.
>
> Because the table names for the m2m fields are generated from the
> class name and the field name together there is scope for them to be
> quite long and to hit the identifier limits and thus under postgresql
> the sequence name auto-generated for the id will not confirm to what
> the code currently guesses it to be (as per #8901) and so there'll be
> an error on updating m2m fields with 1.2 and postgresql in cases where
> there is a long enough field and class name and where it worked fine
> in 1.1. I've hit this myself on updating to 1.2.
>
> As #8901 hasn't been touched in a year (and has been sitting around
> since 2008) I thought I'd have a look at it myself. I've not submitted
> patches or tests for Django before, but I've had a stab at both for
> #8901.
>
> I'm not sure how to get this issue moved along closer to having a fix
> incorporated - it could certainly do with someone more expert than me
> in django and with postgresql knowledge reviewing my patch and tests
> (I've not flagged the issue has "has tests" as I skipped adding a test
> for one change for reasons I've noted on the issue, although maybe I
> should flag it thus).
>
> Regards,
> Matt
>
> --
> 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 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
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: Progressing #8901 "last_insert_id() for postgres fails when the autoincrement sequence name is too long"

[Matt Hoskins]

Hi Russ,

> I've just given your patch on #8901 a quick inspection, and it looks
> good enough to me to progress to RFC (which I've done). I'm hoping to
> have some time tonight to commit some patches; I'll try to put this on
> the list.

Thanks for taking a look at it - I was just wanting to make sure my
updated patch was on someone's radar to get looked at eventually so
it's great to hear you've picked it up  (it's not urgent at all for me
- just thought I'd check before it slipped my mind :). Hope you're
having some luck getting your inbox mopped up!

Regards,
Matt

-- 
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: Decision required: PostgreSQL minimum versions

[Matt Hoskins]

I have already given some of my thoughts on django-users and on the
ticket for 8901... Andrew Godwin's reasoning above feels sound to me,
so considering that and that 1.1 would still work for postgres 7.4
users (plus my desire to see the bug in 8901 fixed sooner rather than
later as it does affect me, although I can patch django myself if I
have to wait to 1.3 so that's only minor) I'd say...

+1 on option 3
+0 on option 2
-1 on option 1

I think if the fix for 8901 isn't put into 1.2 (i.e. option 2 is
chosen) it might be worth adding a note into release notes  for 1.2
about it being a known issue just because the change in m2m saves
means that users (like me) who have a combination of a longish model
name and a longish m2m field name will find things break on upgrading
from 1.1 to 1.2 so you'd want to warn them off doing so!

Matt

-- 
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: Decision required: PostgreSQL minimum versions

[Matt Hoskins]

> If we'd thought of it, dropping 7.4 support in 1.2 would have been the
> right thing to do. However, retroactively doing so now would be abuse
> of the time machine privileges and I'd like to avoid being grounded.
> #1's not worth the effort, so that just leaves #2, which sounds about
> right to me.

Django 1.2 doesn't say which versions of postgresql it supports at the
moment - that may well be just be semantics tho' as I guess anyone
who's tested it will have found it works so far :). I guess people who
are going to hit the bug in #8901 (which may be very few) when
changing from 1.1 to 1.2 will discover the problem in testing so can
hold off on migrating (or apply the patch manually), whereas people
using postgresql 7.4 may already be on version 1.2 and breaking it
working on 7.4 in a point release on 1.2.1 would be less acceptable as
they would already have moved to 1.2 and couldn't then get security
updates for 1.2 [1]

[1] Note that on django-users I did mention that it's possible to
create the function in postgresql 7.x that exists in 8 which the fix
for #8901 relies on, so they have a work around too.

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

Make "required=True" on forms.fields.NullBooleanField do something useful?

[Matt Hoskins]

My use case is that I want to have a BooleanField on the model and on
the form want to have the choices of "Unknown", "Yes" and "No" in a
select list and give a "this field is required" error if the user
leaves it set to "Unknown" (i.e. require them to actively choose "Yes"
or "No", rather than defaulting to either of them). I thought I'd just
be able to use NullBooleanField with "required=True" set, but
NullBooleanField just ignores the "required" argument. To my mind it
would be a sensible use of "required" for NullBooleanField, but before
raising a ticket I thought I'd ask if it was a deliberate oversight or
if what I'm suggesting isn't sensible for some reason :).

Looking at the code for forms.fields.BooleanField and
forms.fields.NullBooleanField I guess the change would be in to_python
in the latter to check in the case where it would return None if
self.required is true and raise the validation error if that's the
case (i.e. similar to what BooleanField.to_python does for values of
False).

Matt

-- 
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: Make "required=True" on forms.fields.NullBooleanField do something useful?

[Matt Hoskins]

For the reasons I gave in my explanation above - which bit isn't
clear?

> If you require a "Yes" or "No" choice, why do you use a
> NullBooleanField in the first place and not a BooleanField ?
>
> George

-- 
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: Make "required=True" on forms.fields.NullBooleanField do something useful?

[Matt Hoskins]

Because "required=True" on a BooleanField means "raise a required
validation error if the value is anything other than True" so although
using that combination that would give me the drop down list, it
wouldn't give me the behaviour I desire which is to only raise the
validation error if None is selected. I could handle it on the form,
it just seems to me that given "required=True" is ignored on
NullBooleanField it would be a sensible (and logical) use for it to
have it mean "require the user to pick either Yes or No".

(George - in case this is where you're not clear - in my use case I
don't want the user to be able to just hit the submit button without
having actively selected either "Yes" or "No" for these fields - if
the choices were just "Yes" or "No" then one of those would have to be
the default and thus the default value would be valid so the user
could just hit submit without interacting with the field, whereas if
the selection list includes "Unknown" and defaults to that, the user
has to interact with the field and change it to "Yes" or "No" to pass
validation).

On Jun 17, 12:07 pm, Hanne Moa  wrote:
> On 17 June 2010 13:01, Matt Hoskins  wrote:
>
> > For the reasons I gave in my explanation above - which bit isn't
> > clear?
>
> Why not reuse the NullBoolean widget with a Boolean field?
>
> HM

-- 
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: Make "required=True" on forms.fields.NullBooleanField do something useful?

[Matt Hoskins]

>
> Looking at the code for forms.fields.BooleanField and
> forms.fields.NullBooleanField I guess the change would be in to_python
> in the latter to check in the case where it would return None if
> self.required is true and raise the validation error if that's the
> case (i.e. similar to what BooleanField.to_python does for values of
> False).

As an aside, I'm now wondering if it's actually incorrect in Django
1.2 that BooleanField.to_python is what does the  self.required check
- shouldn't it be done in a method called validate? The documentation
for the field api for 1.2 says "the to_python()  method on a Field is
the first step in every validation, it coerces the value to correct
datatype and raises ValidationError  if that is not possible" - I'd
argue that False is of the correct data type (i.e. just because
required is set to True doesn't mean that False now is not of the
correct data type for BooleanField) so to_python shouldn't be doing
this check. I think it's probably an oversight as the code that's now
in "to_python" on BooleanField in 1.2 is what was in "clean" in 1.1,
so it was probably just moved wholesale.

Matt

-- 
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: Django, The Web Framework for perfectionists and innovative with rechargeable batteries.

[Matt Boersma]

On Fri, Jul 30, 2010 at 2:57 PM, Jerome Leclanche  wrote:
> [2] People who do have ideas and do write code, but still get rejected
> because their ideas don't conform to whatever the core devs need in
> their websites.

I don't think that's a fair criticism at all.

> ...
> Nice job scaring that poor guy who was just trying to be helpful. His
> first post is met with so much hostility and elitism, I can't imagine
> being him right now.

Ignoring language and newbie barriers, it was not a django-dev post,
and clearly had no spark of idea.  I think jacob and others are
extremely fair and tolerant in moderating this list.

-- 
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: Solving the POST-data-lost-after-redirect problem

[Matt McDonald]

You could also use Tidy, there's a couple python wrappers for it:

TidyLib wrapper: http://utidylib.berlios.de/
Classic Tidy: http://www.egenix.com/files/python/mxTidy.html

Which should work on all platforms and can even be used to correct  
the page before outputting it.

On 08/06/2006, at 1:00 PM, Max Battcher wrote:

>
> Luke Plant wrote:
>> I'm not sure how useful it is for Mac and Windows users.  The  
>> middleware
>> doesn't actually do any validation -- it's done by 'validate' from
>> Debian's 'wdg-html-validator'.  I personally wrap that in a shell
>> script which beeps and pops up a KDE notification when a page fails.
>
> For the notifications you could switch to Jabber notifications.  Plus,
> you get the benefit of free remote notifications and logging...
>
> The validator I'm not so sure about.  WDG's appears to be Perl, so you
> could just make Windows/Mac users install perl.
>
> -- 
> --Max Battcher--
> http://www.worldmaker.net/
> "I'm gonna win, trust in me / I have come to save this world / and in
> the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track)
>
> >


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

Re: Proposal: default escaping (and branch request)

[Matt McDonald]

If you don't ever want to display the html then it shouldn't be  
stored in the first place. The escaping/removing should be done when  
processing the input. What's better:

1. escaping/removing when the data is saved (one time occasion) or
2. escaping/removing each time the data is used (infinite times)

So I think we should be concentrating more on what gets through the  
input and stored rather than worrying about if something needs to be  
escaped or not and by default or not.

On 22/06/2006, at 1:50 PM, James Bennett wrote:

>
> On 6/21/06, Tyson Tate <[EMAIL PROTECTED]> wrote:
>> Then again, how often do you *want* to allow your users to put HTML
>> and JS in and allow it to be executed? Not often, I imagine.
>
> This depends completely on the type of application. Some applications
> will have very little HTML input by users, but some applications may
> have tons and tons of HTML input by users.
>
>> And
>> following that, I think Django should, of the two options, cover the
>> majority, which I believe is "escape by default" and allow {%
>> autoescape off %}. For the sake of security, I'm really hoping to see
>> escaping automatically turned on.
>
> Has the world honestly learned not one single solitary thing form
> PHP's magic_quotes fiasco? Autoescaping all output by default is
> something that is unequivocally not acceptable.
>
> -- 
> "May the forces of evil become confused on the way to your house."
>   -- George Carlin
>
> >


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

Re: simonslaw/matt the destroyer

[Matt Carter]

Unfortunately, "Matt the Destroyer" (me) is a completely different
person than "simonslaw."

I'd appreciate being removed from the ban list.


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

Re: Consider releasing a .95 beta

[Matt Howell]

Regardless of the merits of the issue, it certainly doesn't help things
to get personal.

If you want to influence the process, stay cool and keep the emotional
attacks off the 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
-~--~~~~--~~--~--~---

Re: Oracle: call for testing

[Matt Boersma]

Here is the current status of Oracle support:

- Some of the backend files are already in subversion trunk, but not
enough to make it functional.  Don't bother testing (or patching)
Oracle support in the trunk--the branch is where the action is.
- Some Colorado developers, along with Jacob Kaplan-Moss, made a
valiant attempt to finish Oracle support at a sprint about two months
ago.  That's now the boulder-oracle-sprint branch.
- To run the unit test suite, do "python tests/runtests.py
--settings=myproject.settings" from the root of the
boulder-oracle-sprint branch.  Make sure myproject.settings is a python
module in your PYTHONPATH that is configured to connect to an Oracle
database.  The Oracle user you specify must have DBA-type privileges,
since the tests create and destroy tables, indexes, triggers, and
tablespaces.  (Also don't include a CACHE_BACKEND in settings.py, or
the cache-related tests will fail.)
- Currently, only two tests fail against Oracle.  We could really use
help fixing those!
- A bigger problem is the potential column name collision owing to the
fact that our paging query uses a "SELECT *" construct around the main
SQL.  (Don't scold me; we're trying to fix it.)
- Another issue is that Date and DateTime fields show up as Boolean
values in the Admin.
- I merged changes from the django trunk into the boulder-oracle-sprint
branch today, and will continue to do so on a weekly basis until Oracle
support is in the trunk.

Questions about Django development in general are answered here:
http://www.djangoproject.com/documentation/contributing/


--~--~-~--~~~---~--~~
 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: Error ORA-00918 (column ambiguously defined)

[Matt Boersma]

This is now fixed in the current boulder-oracle-sprint branch, as of
changeset [4277].


--~--~-~--~~~---~--~~
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: Oracle: call for testing

[Matt Boersma]

Andreas, I finally got around to applying and testing your patch.
Thanks very much--it makes the Oracle test environment much more
flexible.


--~--~-~--~~~---~--~~
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: Oracle indexes and tablespaces

[Matt Boersma]

At the Django-Oracle sprint a couple months ago, we discussed having an
optional "tablespace" parameter when defining models, but not a
separate one for the index tablespace.  We didn't get around to
implementing it.

In Oracle-land, your requirement is actually common, not unique.  I
think it's important to be able to specify table and index tablespaces
if we want Django to fit well into real Oracle environments.  For now,
I'm doing "manage.py syncdb" against a local Oracle XE instance I
control, then taking the output of "manage.py sqlall" and editing it as
necessary for production.

Someone mentioned a branch or patch that allowed for passing through
arbitrary additional arguments to a Model.  That could be a clean
solution to this problem--does anyone know where such code lives now?


--~--~-~--~~~---~--~~
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: SQL generated from oracle-boulder-sprint doesn't work with Oracle9i

[Matt Boersma]

Frank, I've been doing as much maintenance and bug fixing as I can on
the boulder-oracle-sprint branch.  I test against 9i as well as 10g
XE.

If you could do as James suggests and post a detailed bug report at
http://code.djangoproject.com/, I'll take a look and get it fixed.

thanks,

Matt

On Mar 19, 1:58 am, "frank h." <[EMAIL PROTECTED]> wrote:
> Hello,
> I am trying to use Django with an Oracle9i database (the server
> version is "Oracle 9i Enterprise Edition Release 9.2.0.7.0 - 64bit
> Production")
>
> using cx_Oracle, i can connect to the database fine. sqlplus and all
> other tools I've tried connect just fine. It is upon executing
>
>   manage.py install <>
>
> that things go wrong, the database engine complains about the SQL that
> django is generating. I am by no means a database or SQL expert, but I
> showed the output of manage.py sqlall <> to our DBA, and he
> pointed out the syntax errors to me.
>
> My questions are:
>   - who is maintaining this oracle branch and how can I get in touch
> with them (I looked on the wiki but found no branch homepage, this
> would maybe be a good idea to create?)
>   - can somebody look at the SQL I get from manage.py and either
> confirm that its a problem (in which case I could file a bug) or tell
> me what is going wrong?
>
> I can't even get the admin to install, this has nothing to do with
> models that I have created. I assume though that the oracle branch is
> able to create the admin tables in an oracle database (I could not
> find any information to the contrary)
>
> ok, thanks for your help
> -frank


--~--~-~--~~~---~--~~
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: GeoDjango query with foreign keys

[Matt Bartolome]

I wouldn't think this would actually work but I just put the objects =
models.GeoManager() on my model and it now knows what to do with the
spatial queries. Excellent.


On 4/17/07, mattxbart <[EMAIL PROTECTED]> wrote:
> Hey guys, I'm working with the GeoDjango branch and I was wondering if
> there are any plans to allow something like I have below:
>
> >>> ParcelSale.objects.filter(parcel__poly__contained=cpa.get_poly_wkt())
>
> "parcel" is a foreign key to the geometry model information:
>
> class Parcel(models.Model,models.GeoMixin):
> gid = models.IntegerField(db_column='gid',primary_key=True)
> apn = models.CharField(db_column='apn',maxlength=10)
> poly = models.PolygonField(db_column='the_geom',srid=4269,
> index=True)
> zip = models.CharField(db_column='zip', maxlength=5)
> objects = models.GeoManager()
>
> I can do spatial queries if they are directly between two models with
> polygon fields but I can't seem to get at the spatial queries through
> foreign keys.
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/site-packages/django_gis/django/db/models/query.py", line
> 102, in __repr__
> return repr(self._get_data())
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/site-packages/django_gis/django/db/models/query.py", line
> 470, in _get_data
> self._result_cache = list(self.iterator())
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/site-packages/django_gis/django/db/models/query.py", line
> 174, in iterator
> select, sql, params = self._get_sql_clause()
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/site-packages/django_gis/django/db/models/query.py", line
> 484, in _get_sql_clause
> joins2, where2, params2 = self._filters.get_sql(opts)
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/site-packages/django_gis/django/db/models/query.py", line
> 648, in get_sql
> joins2, where2, params2 = val.get_sql(opts)
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/site-packages/django_gis/django/db/models/query.py", line
> 699, in get_sql
> return parse_lookup(self.kwargs.items(), opts)
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/site-packages/django_gis/django/db/models/query.py", line
> 831, in parse_lookup
> joins2, where2, params2 = lookup_inner(path, lookup_type, value,
> opts, opts.db_table, None)
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/site-packages/django_gis/django/db/models/query.py", line
> 970, in lookup_inner
> joins2, where2, params2 = lookup_inner(path, lookup_type, value,
> new_opts, new_table, join_column)
>   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/
> python2.5/site-packages/django_gis/django/db/models/query.py", line
> 938, in lookup_inner
> raise TypeError, "Cannot resolve keyword '%s' into field" % name
> TypeError: Cannot resolve keyword 'poly__contained' into field
>
> Thanks,
> Matt
>
>

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

A shortcut for django.core.urlresolvers.reverse

[Matt Riggott]

Hi folks,

Something I find myself writing for each new Django project is a small
wrapper for the django.core.urlresolvers.reverse function.  It usually
looks something like this:

from django.core.urlresolvers import reverse

def absolute_url(viewname, *args, **kwargs):
return reverse(viewname, args=args or [], kwargs=kwargs or {})

It means I can have that warm, fuzzy feeling when I see my views don't
have any hard-coded URLs.  For example:

def some_view(request, id):
some_object = get_object_or_404(SomeModel, id=id)
if request.method == 'POST':
# Some code that changes the database here.
return HttpResponseRedirect(absolute_url(some_other_view))
else:
# Render the page here.

Assuming the URL pattern for the view above is '/event/(?P\d+)/',
a couple of other examples  are:

>>> some_id = 1
>>> absolute_url(some_view, id=some_id)
'/event/1/'
>>> absolute_url(some_view, some_id)
'/event/1/'

Is there any chance this could be included in Django?  It might sit
nicely in somewhere like django.shortcuts.

A nice side-effect would be that it could be used in place of the few
hard-coded URLs that are still hanging around in Django — in
django.contrib.auth for instance:

LOGIN_URL = absolute_url('django.contrib.auth.views.login')

Is it worth me submitting a patch?

M.

-- 
Matt Riggott (mailto:[EMAIL PROTECTED]).
Dictated but not read.

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

Oracle patch is ready

[Matt Boersma]

The "boulder-oracle-sprint" branch is ready to come home.

We made a wiki page describing the goals and status of the code (quick
summary: Oracle works and we think it's done, unless you tell us
otherwise).  Attached to that page is a patch against rev 5036 of the
trunk.  See here:
http://code.djangoproject.com/wiki/OracleBranch

The diff itself is here:
http://code.djangoproject.com/attachment/wiki/OracleBranch/django-oracle-rev5036.diff

This is a "non-trivial patch," we believe, so rather than attaching it
to the closed Trac bug #1990, we're advertising it here as recommended
on the "Contributing to Django" page.  There are some minor
architectural changes in there, although we've made every effort to
minimize the overall deltas.

Please review the patch if you're able to and let us 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-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: Oracle patch is ready

[Matt Boersma]

+1 on what Jim said, and since we are using this code in production at
Array BioPharma, we will stay on top of it.  If you need an individual
point of contact, I can be that, and Ian Kelly and I will be
monitoring the mailing lists and Trac more actively and responding to
Oracle-related issues.

Matt

On Apr 19, 10:08 pm, Jim Baker <[EMAIL PROTECTED]> wrote:
> Jacob,
>
> As we discussed at PyCon, we can make an even stronger commitment,
> since this continues to be an official project for the Front Range
> Pythoneers in Boulder. But people ultimately get this work done, so
> kudos go to ring leader Matt Boersma, the intrepid Ian Kelly, Eric
> Dobbs, Matt Drew, Michelle Cyr, and Mitch Smith for making this
> happen.
>
> And a special thanks to you for coming out on an early flight from
> Lawrence and working with us in Boulder on Saturday, Nov 4, that did
> make all the difference. (For those interested in user group
> sprinting, I'll plug it here,http://wiki.python.org/moin/BoulderSprint
> :)
>
> - Jim
>
> On Apr 19, 10:08 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
> wrote:
>
> > On 4/19/07, Matt Boersma <[EMAIL PROTECTED]> wrote:
>
> > > The "boulder-oracle-sprint" branch is ready to come home.
>
> > Wahoo!!
>
> > Just to clarify, Matt: you're willing to commit to maintaining Oracle
> > support once we merge this into trunk, yes? If so, I'm +1 on merging
> > this in (there's a few things we had to do I'm not 100% thrilled with
> > -- in particular the QS method overriding hack) but I'm OK fixing that
> > stuff a bit later. I'd love to get this to be an "official" feature!
>
> > Jacob


--~--~-~--~~~---~--~~
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: Oracle patch is ready

[Matt Boersma]

Ben Khoo already found a good bug (#4093) that we fixed, and in the
process we found a problem we'd created for Postgres that wasn't
caught by any of the tests.  So we fixed that and added a "datatypes"
test to modeltests.

So there is a slightly newer patch available now:
http://code.djangoproject.com/attachment/wiki/OracleBranch/django-oracle-rev5046.diff

We'll try not to do this again so people can focus on the content of
the patch for a bit, but these two things needed to be fixed ASAP.  If
you're testing the boulder-oracle-sprint branch directly, please
update.

Matt

On Apr 20, 10:03 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 4/19/07, Matt Boersma <[EMAIL PROTECTED]> wrote:
>
> > The "boulder-oracle-sprint" branch is ready to come home.
>
> Congrats, guys! Thanks to all of you for your hard work. I'm +1 for
> merging it, too, once we've taken a look at it.
>
> Let's organize the merge process. Malcolm, since you've been dealing
> with query.py and other databasey parts of Django, do you want to take
> the lead on the merge? Or Jacob? I could get to it next week if you
> guys are busy.
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com


--~--~-~--~~~---~--~~
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: Oracle patch is ready

[Matt Boersma]

That's a good point, Ben.  There isn't any way to propagate the
db_tablespace parameter back to models not directly under your
control, like auth, sessions, etc., so the db_tablespace parameter we
added is only a halfway solution.

Our thinking was that for any "real" Oracle deployment, chances are
high that you'll want to take the output of "./manage.py sqlall" and
at least modify the index and row tablespaces, as well as create more
specific grant permissions (and change LOBs to be stored out-of-table,
and...).  We are unlikely to please a full-time Oracle DBA with the
DDL we create no matter what we do, given the richness of Oracle's
storage options.

Having the db_tablespace parameter makes at least the models under
your control more self-documenting.  But it's not perfect.  Here are
the three options I can think of:
- Leave as-is, realizing it helps somewhat
- Drop the "db_tablespace" and index tablespace keywords altogether to
avoid this confusion
- Add a mechanism for a default global tablespace and global index
tablespace that apply unless overridden in a specific model or column

Thoughts?

Matt


On Apr 22, 10:02 pm, benk <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have been using the Oracle branch now for a few months and it is
> looking really good.
>
> I have a question regarding the use of the 'db_tablespace' option in
> the Meta class. I am able to set this option within my application and
> successfully perform a syncdb that will place all my tables in the
> correct tablespace. The question/issue that I am having is that I
> cannot see a way of instructing any other application (such as
> authentication) to also create its tables in the tablespace of my
> choosing.
>
> To my understanding the application will either create its tables in
> the tablespace specified in its own models.py or it create its tables
> in whatever the default tablespace happens to be. This results in
> tables being created in several different tablespaces.
>
> For my 2c worth, if this cannot already be done by the current Oracle
> database framework, I think that would be a beneficial addition if
> only to provide completeness to the option to assign tablespaces.
>
> Regards
> Ben Khoo
>
> On Apr 21, 1:54 am, Matt Boersma <[EMAIL PROTECTED]> wrote:
>
> > Ben Khoo already found a good bug (#4093) that we fixed, and in the
> > process we found a problem we'd created for Postgres that wasn't
> > caught by any of the tests.  So we fixed that and added a "datatypes"
> > test to modeltests.
>
> > So there is a slightly newer patch available 
> > now:http://code.djangoproject.com/attachment/wiki/OracleBranch/django-ora...
>
> > We'll try not to do this again so people can focus on the content of
> > the patch for a bit, but these two things needed to be fixed ASAP.  If
> > you're testing the boulder-oracle-sprint branch directly, please
> > update.
>
> > Matt
>
> > On Apr 20, 10:03 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
>
> > > On 4/19/07, Matt Boersma <[EMAIL PROTECTED]> wrote:
>
> > > > The "boulder-oracle-sprint" branch is ready to come home.
>
> > > Congrats, guys! Thanks to all of you for your hard work. I'm +1 for
> > > merging it, too, once we've taken a look at it.
>
> > > Let's organize the merge process. Malcolm, since you've been dealing
> > > with query.py and other databasey parts of Django, do you want to take
> > > the lead on the merge? Or Jacob? I could get to it next week if you
> > > guys are busy.
>
> > > Adrian
>
> > > --
> > > Adrian Holovaty
> > > holovaty.com | djangoproject.com


--~--~-~--~~~---~--~~
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: Oracle patch is ready

[Matt Boersma]

I had purposely let this thread dangle, hoping Malcolm or Adrian or
Jacob might weigh in and decide the "db_tablespace" minor controversy.

But I hope this unresolved issue isn't perceived as holding up
integration of the Oracle patch.  I don't think it should.  At worst,
we could strip out the "db_tablespace" options altogether to simplify
the patch, then resurrect it as a separate patch on trunk once we know
which of the below options is preferred.  I also think it's ok to
leave it as-is for now.

So this is my "ping" to see if there's any general feedback on the
patch, and if there's any way we can facilitate it getting
incorporated.  Not a complaint!  [ducks head]

thanks,

Matt


On Apr 23, 7:21 pm, benk <[EMAIL PROTECTED]> wrote:
> Hi Matt,
>
> I can see where you are going regarding the manual "massaging" of
> "sqlall" output to create the database tables. My primary reason for
> the post was to ensure that I did not miss a piece of documentation
> showing how the tablespace could be set for other applications.
>
> To clear up potential misconceptions, I am most certainly not an
> Oracle DBA. Far from it. I am merely a lowly programmer who is
> currently working with Django.
>
> For the moment, I have worked around the issue of tables appearing in
> different tablespaces by creating an Oracle user configured to use a
> specific default tablespace which is the same as the db_tablespace.
> This means that for applications like auth where the db_tablespace is
> not specified, Oracle will create the table in my configured default
> tablespace. All of this of course happens at the user creation level
> in Oracle and makes the explicit setting of the db_tablespace option
> redundant.
>
> In my personal opinion (that I encourage those with higher powers to
> overrule as required) I think that it is leaving the db_tablespace
> option "as is" would be completely acceptable with the addition of a
> note to prevent misconceptions like mine. The only disadvantage that I
> can see with this path is that this option is a "halfway solution" as
> you put it and only applies to Oracle. This may lead to a longer term
> cluttering of the Django API for limited gain.
>
> Ben


--~--~-~--~~~---~--~~
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: Question for Oracle Boulder sprinters

[Matt Boersma]

On May 11, 8:37 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> ...
> So should the Oracle branch be ignoring the null attribute when
> blank=True and assuming null=True in that case?

I think that's reasonable.  It may mean a couple of unit tests fail,
so we can either modify them or at least document that this is
expected with the Oracle backend.  We had considered doing this
before, but probably opted against it since we were focused on passing
all the tests.

Our current approach in this case is to map an empty string to a
single space char when storing, and the opposite when loading.

We'll try to implement your suggestion above ASAP unless someone has
major objections.

Matt


--~--~-~--~~~---~--~~
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: New mailing list: django-updates

[Matt Croydon]

Adrian,

Rock on!  I think it would also be helpful to have a cia bot sending
updates to #django (I think we mentioned this awhile back but wanted
to highlight its usefulness again).  The URL is http://cia.navi.cx/
and I'm pretty sure that it's pretty easy to set up.

--Matt

On 9/1/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> 
> Hi all,
> 
> I've created a new mailing list, django-updates, that sends out a
> message each time a change is made to the Django codebase or ticket
> system. It's a read-only mailing list.
> 
> Its Google Groups page is here:
> http://groups.google.com/group/django-updates
> 
> Adrian
> 
> -- 
> Adrian Holovaty
> holovaty.com | djangoproject.com | chicagocrime.org
> 


-- 
...
Matt Croydon
[EMAIL PROTECTED], [EMAIL PROTECTED]
http://postneo.com

Re: Schema evolution

[Matt Croydon]

On 2/27/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
Any thoughts before I start on this?I'm definitely +1 on this.  The flexibility of using SQL or Python for migration lets people use the tools that they are most familiar/comfortable  with.  While I think that anyone with "real" data to worry about should use to_version_X.out to ensure integrity, making it optional is key for keeping it simple for the newbs.
--Matt

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

Re: Template tag magic that hasn't been removed

[Matt Croydon]

After trawling around the magic with James I have to say that I'm for this particular bit of magic.  The alternative is to walk all subdirectories of INSTALLED_APPS and look for someting that looks like a taglibrary.  I'm not sure if it can be done any more efficently, but I'm a little worried about this cost every time someone uses {% load custom_taglib %}.
I'm totally fine with removing this particular bit of magic, but only if there's not a significant decrease in performance in the template system.--MattOn 4/26/06, 
James Bennett <[EMAIL PROTECTED]> wrote:
I got bitten by ticket #1675 today, and took some time to work outexactly what was going wrong. It turned out I was setting up my customtag library incorrectly, but the process revealed some magic thatmagic-removal hasn't gotten rid of.
In looking at how the 'load' tag is implemented, I was confused as towhy it only searched in 'django.templatetags' (and hence, why theInvalidTemplateLibrary exception I was getting only ever said that it
had looked in 'django.templatetags'). The answer surprised me.If you have a peek at django/templatetags/__init__.py [1], you'llnotice that it loops over everything in INSTALLED_APPS and, for eachapp, adds the __path__ of that app's 'templatetags' directory to the
__path__ of 'django.templatetags'. The result of this is that all thetemplate tag libraries appear to be under 'django.templatetags'.It's obvious that this qualifies as 'magic'. What's less obvious iswhether it's magic that should be removed; it's magic, but it's magic
that's nigh invisible to end users of Django -- only the templatetagloading system ever knows that this happens, and if you ever want toimport a templatetag library manually you can do so using itsconventional Python path. So removing it would basically be removing
magic for the sake of removing magic, not removing magic because it'sharmful or confusing. Additionally, the alternative would seem to behaving the 'load' tag loop over INSTALLED_APPS looking for templatetag
libraries every time it's asked to load a library, and I imagine thatcould have an adverse effect on performance.But it's still magic, and it means that any given tag library can beimported from either of two locations -- its actual conventional
Python path, and its "magic" location in 'django.templatetags'.So... should this bit of magic stay, or should it go?On a related note: at some point we might want to re-think the conceptof "registering" a templatetag library, since doing so doesn't
actually seem to update any "registry" of libraries -- the only timesuch a registry is generated is when django/templatetags/__init__.pyis executed, and it doesn't seem to care one way or another if the
library has been "registered". Perhaps the ubiquitous convention of"register = Library()" could be changed to something more conceptuallyappropriate?[1] 
http://code.djangoproject.com/browser/django/branches/magic-removal/django/templatetags/__init__.py--"May the forces of evil become confused on the way to your house."  -- George Carlin
...Matt Croydon[EMAIL PROTECTED], [EMAIL PROTECTED]http://postneo.com

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

Re: authentication by email

[Matt Pegler]

For the project I am working on, we solved this by making a custom
auth backend that checks the username against the email column.  We've
found it to be a nice clean solution to wanting to use email addresses
instead of usernames.

On Thu, Mar 8, 2012 at 9:54 PM, Clay McClure  wrote:
> "Django is a high-level Python Web framework that encourages rapid
> development and clean, pragmatic design"—unless you want to do something
> seemingly simple like using email addresses for authentication, in which
> case you need to monkey patch models and forms to get everything working
> right, which is neither rapid nor clean. What began as an innocuous feature
> request five years ago is now a high-level, general purpose, abstract,
> seemingly insurmountable design problem. The core developers are still
> perfectionists, but they seem to have forgotten their deadlines.
>
> Is there not a simple, pragmatic solution (optional and for new
> installations—we're not talking about backwards compatibility here) that
> could be implemented until the panacea of pluggable User models gets figured
> out? Something as simple (albeit ugly) as wrapping new models and forms in:
>
> if settings.AUTH_EMAIL_AUTHENTICATION:
>
> Should these things really take five years? What happened to pragmatic?
>
> Clay
>
> --
> 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/-/KebjFDOOBF4J.
> 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.

-- 
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: authentication by email

[Matt Pegler]

Sorry all, disregard my previous email, I misread one thing and
completely missed Wim's original message.

On Thu, Mar 8, 2012 at 11:07 PM, Matt Pegler  wrote:
> For the project I am working on, we solved this by making a custom
> auth backend that checks the username against the email column.  We've
> found it to be a nice clean solution to wanting to use email addresses
> instead of usernames.
>
> On Thu, Mar 8, 2012 at 9:54 PM, Clay McClure  wrote:
>> "Django is a high-level Python Web framework that encourages rapid
>> development and clean, pragmatic design"—unless you want to do something
>> seemingly simple like using email addresses for authentication, in which
>> case you need to monkey patch models and forms to get everything working
>> right, which is neither rapid nor clean. What began as an innocuous feature
>> request five years ago is now a high-level, general purpose, abstract,
>> seemingly insurmountable design problem. The core developers are still
>> perfectionists, but they seem to have forgotten their deadlines.
>>
>> Is there not a simple, pragmatic solution (optional and for new
>> installations—we're not talking about backwards compatibility here) that
>> could be implemented until the panacea of pluggable User models gets figured
>> out? Something as simple (albeit ugly) as wrapping new models and forms in:
>>
>> if settings.AUTH_EMAIL_AUTHENTICATION:
>>
>> Should these things really take five years? What happened to pragmatic?
>>
>> Clay
>>
>> --
>> 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/-/KebjFDOOBF4J.
>> 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.

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

finding the source of "interesting" SQL queries

[Matt McClure]

>From time to time the pager goes off, and I need to find the source of a 
given query hitting MySQL. It might be poorly performing, or flooding MySQL 
in high volume. In any case, I'd love some instrumentation that could point 
me at a lead in my Django site that's more specific than a given user or IP 
address. I'm considering adding a comment to the query that includes some 
part of the call stack, possibly based on Ned Batchelder's "global request" 
code[1]. Is there a community maintained solution to similar problems 
already in the wild? Or failing that, an approach that the community would 
like to include in Django?

[1]: http://nedbatchelder.com/blog/201008/global_django_requests.html

--
Matt McClure
http://www.matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure

-- 
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/-/PAcaIZ8CvlUJ.
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: finding the source of "interesting" SQL queries

[Matt McClure]

Thanks, Russell. That's similar to the approach we were thinking of 
implementing. Hopefully we'll have a straw man to share shortly. 

Matt

-- 
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/-/ANmX3ZuR7oMJ.
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.

Github tags

[Matt Austin]

Hi,

Would it be possible to get tags for 1.3.3, 1.3.4, 1.4.2, and 1.5
alpha tagged on the github repository? The tagging seems to have
fallen behind with these releases.

Thanks,

-- 
Matt

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

ModelMultipleChoiceField, clean and to_python

[Matt Hoskins]

The validation documentation for forms says that to_python on the form 
field is the first step in validation. I've written some code (the details 
of which don't really matter) which makes use of to_python on fields in 
doing so I discovered that "to_python" on ModelMultipleChoiceField doesn't 
work. The reason for this is that ModelMultipleChoiceField inherits from 
ModelChoiceField but then puts everything into "clean" and doesn't do 
anything about "to_python".

I would guess it was quicker/easier to put everything together in "clean" 
when the method was originally authored?

Given "to_python" is documented in forms as being a first step it feels to 
me untidy, at least, that this "to_python" is hanging around on 
ModelMultipleChoiceField in a non-working state and also that everything is 
put into "clean" - it would feel tidier to move the "to_python"-ish parts 
of ModelMultipleChoiceField out of "clean" and into "to_python". I also 
wonder if the "required" and "invalid_choice" tests from "clean" ought to 
be put into a "validate" method to make it consistent with how other fields 
behave, although I note from ModelChoiceField that an invalid choice cannot 
be converted to python since an instance can't be found for it so maybe 
to_python is the appropriate place for the invalid_choice test at least! I 
describe as "untidy" rather than as a bug as I'm not clear whether the 
documentation on validation is suggesting fields should have a "to_python" 
method and/or whether it's reasonable to expect "to_python" methods (if 
they exist) on form fields should work.

Worth me raising this as a ticket? Or is it a non-issue or there's a valid 
reason for keeping things as they are in ModelMultipleChoiceField's clean 
method?

Matt

-- 
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/-/Uex-m8HYproJ.
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.

Feedback #24496 - Check CSRF Referer against CSRF_COOKIE_DOMAIN

[Matt Robenolt]

Ticket and patch have been submitted regarding this:

https://code.djangoproject.com/ticket/24496
https://github.com/django/django/pull/4337

Since this is related to CSRF and technically weakening the strictness of 
the Referer check, Tim Graham suggested soliciting feedback here to get 
more eyeballs and feedback.

Please let me know if there's more context needed that can be added to the 
ticket.

My tl;dr is that Django should allow a Referer match across a subdomain, 
and not exactly matching `request.get_host()` since cookies are allowed to 
be set on subdomains as well. This is similar in vain to ALLOWED_HOSTS, 
except Django would purely validate against the CSRF_COOKIE_DOMAIN.

Thanks. <3

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/461ac976-18f5-4c40-9e10-0f15cd0eb3f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Potentially inconsistent behavior between test client and normal WSGI requests

[Matt Hooks]

Hi all,

As I was fixing an issue in our API related to url encodings, I noticed a 
problem should have been caught by a test that was somehow passing. 
 (Remember, make sure your test can fail!)

If you had some path /some/path/Spam%20Ham, and a URL pattern to capture 
/some/path/(?P.+)$, it's not unreasonable to think to think your named 
capture would pick up "Spam Ham" (with an actual space) and send that to 
your view.  And indeed it does exactly that, when you make that request 
through the Django test client.  

This is because there's an explicit call to unquote in 
django.test.client.RequestFactory before proceeding to build a WSGIRequest.

(The behavior of the development server is similar to the test client, 
although I haven't investigated for what exact reason.)

But when an actual WSGI server makes the same call, WSGIHandler doesn't 
make that same call to unquote; it passes the exact URL through to 
WSGIRequest. This leads to a scenario where, in the above example, views 
will see "Spam Ham" as the value of foo in unit tests, but will see 
"Spam%20Ham" when run in production.

This strikes me as bug worthy.  I don't have *particularly *strong feelings 
on which is the correct behavior, but both behaviors should be the same.

I'd be willing to take on the patch once I get some input from others.

Thoughts?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/aecc395b-eb4f-4046-96bf-46ea74b4e68d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Potentially inconsistent behavior between test client and normal WSGI requests

[Matt Hooks]

Took me a few minutes to narrow down the right environment to recreate 
this.  

I'm seeing this "issue" with Gunicorn (latest version ,19.3.0), and only 
when using the gaiohttp async worker (again latest version of aiohttp, 
0.15.3).  I've tracked it down to the troublesome line in aiohttp, but I 
imagine that isn't terrible relevent here.

I'm not really familiar with the design ideals of the Django devs or the 
WSGI spec.  From what I can tell, the spec doesn't specify whether the url 
should be unquoted before passing it to the application.  This leaves us 
with the possibility of changing behavior when moving among different WSGI 
servers.  While any decent developer should know there will be differences 
when they reconfigure their stack, it might make sense to ensure 
consistency for this particular detail.  The only concern would be 
backwards compatibility, but from what I can tell, most of the gunicorn 
worker types currently already behave this way**, along with uwsgi.  I 
imagine the majority of people are using one of those, so I doubt any 
signficant number are relying on this behavior, but I dont have much to 
back that up with.  I havent checked any other implementations, like 
mod_wsgi.

I suppose this boils down to whether or not Django should be normalizing 
the url path (PATH_INFO) from the WSGI server, or should just go with 
whatever it is provided.

(** All the ones I checked, specifically sync, eventlet and tornado.  The 
gevent ones dont play nice with my python3 install.)

On Friday, April 24, 2015 at 5:07:59 PM UTC-4, Florian Apolloner wrote:
>
>
>
> On Friday, April 24, 2015 at 10:51:12 PM UTC+2, Matt Hooks wrote:
>>
>> (The behavior of the development server is similar to the test client, 
>> although I haven't investigated for what exact reason.)
>>
>
> To be honest, even on my production machines I have this behavior -- so 
> the question is which "production" server you are using and which versions 
> of $stuff.
>
> Cheers,
> Florian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/271b15b5-2ff0-49b2-a5eb-c87ed99a5b04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Potentially inconsistent behavior between test client and normal WSGI requests

[Matt Hooks]

I've checked against the wsgiref module and you are most certainly correct: 
unquoting PATH_INFO is the job of the wsgi server.

I'll being up the issue with with the aiohttp folks.  Thanks for your time.


On Saturday, April 25, 2015 at 3:02:50 AM UTC-4, Florian Apolloner wrote:
>
>
>
> On Saturday, April 25, 2015 at 8:46:58 AM UTC+2, Matt Hooks wrote:
>>
>> I'm not really familiar with the design ideals of the Django devs or the 
>> WSGI spec.  From what I can tell, the spec doesn't specify whether the url 
>> should be unquoted before passing it to the application.
>>
>
> I think the WSGI spec somewhat follows the CGI spec which says:
> Unlike a URI path, the PATH_INFO is not URL-encoded, and cannot contain 
> path-segment parameters.
>
> So to my understanding this seems to be a bug in whatever you use, no?
>
> Cheers,
> Florian
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/0fa133ed-4006-4295-bded-ba29c18055c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Queryset values() differentiate between requests for model objects and model IDs

[Matt C]

If I have some models like so:

from django.db import models

class X(models.Model):
y = models.ForeignKey(Y)
... other fields ...

class Y(models.Model):
... some fields ...



... and I do a query like so:

X.objects.all().values('y')

... I get back a list of dictionaries that contain Y ID integers.

If I do a query like so:

X.objects.all().values('y_id')

...I get back a similar result, except for the keys in the dictionaries.

My proposal is to differentiate between those two calls and in the former 
case, instead of returning the same results as the latter case, return Y 
model objects.

Not only would this produce results that are more indicative of what the 
query is asking for, but it would extend the ORM in at least one area:
http://stackoverflow.com/questions/30113766/aggregrate-query-with-related-models-not-just-related-id-values

Those kinds of aggregrate queries would be possible.

As far as backwards compatibility is concerned, the old behaviour could 
occur with no key word argument to the values() call, but if a keyword 
argument like so:

X.objects.all().values('y', select_related=True)

...is specified, then my proposed behaviour could be executed.

What do you think?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/4adaa5a3-f6d3-4189-8bb5-83eb5c4f2648%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Matt Austin]

On 11 June 2015 at 01:37, Collin Anderson  wrote:
>
> I'd propose something slightly different, that's very close to our current
> deprecation timeline:
> 1.8 (LTS): No features dropped.
> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
> 2.0: Dropped features deprecated in 1.8
> 2.1 (LTS): No features dropped.
> 2.2: Dropped features deprecated in 1.9, 2.0
> 2.3: Dropped features deprecated in 2.1
>
> Seems to me features deprecated in an LTS are fair game to disappear in the
> next LTS. This allows us to remove "dotted paths in reverse() and url()"
> because that's deprecated in 1.8.
>
> If we can guarantee compatibility between LTSs, I think that would be a huge
> win, at the cost of extending the removal of some deprecated features by one
> release (8 months).
>

Hi everyone,

Sorry to stick my nose in, but thought I might throw a potential
spanner-in-the works with this release discussion, in regard to
version naming.

I understand that the current version system doesn't have too much
inherent meaning, and that 2.0 will come after 1.9 'just so we don't
stay on 1.x forever'.

With a more structured release plan, and LTS releases, would it be
worth considering LTS releases as 'major' version numbers, with
regular releases and 'minor' version releases? It would be easier to
identify LTS releases at a glance, and might provide more meaning to
the versioning scheme?

Feel free to shut this idea down if it's going to open a can-of-worms :)


Cheers,

--
Matt

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CACATwqQge_4Bx%2BctJFsf02uTyhu9gy4GMBaUHx23XUEY6yXCuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name"

[Matt Hoskins]

Working on some code I've hit that the reverse name for a
OneToOneField cannot be used, it seems, in values_list or values. I
couldn't see why there would need to be such an exclusion, given it is
a one-to-one relationship, so am wondering if it's just an oversight
in the code or a deliberate exclusion?

The portion of code that is rejecting doing e.g.
"values_list('onetoonereversename')" is in setup_joins where the if
line reads:

if not allow_many and (m2m or not direct):

The values of "m2m" and "direct" come from opts.get_field_by_name and
it seems that the reverse of a OneToOne gives the same results as the
reverse of a ForeignKey, as of course both are not m2m and are not
direct. Looking at the code later on in setup_joins it describes the
path where direct is false and m2m is false as being "One-to-many
field (ForeignKey defined on the target model)", so it looks like the
logic I've quoted above of "if not allow_many and (m2m or not direct)"
has the "not direct" clause in to reject reverse ForeignKey
relationships and in doing so also rejects reverse OneToOne
relationships (and with the latter case I suspect it need not!).

If someone a bit more knowledgeable about the query machinery could
comment on whether it does look like an oversight or is a deliberate
exclusion, then if it's the former I'll log it as a bug.

Assuming the rest of the code is ok in the case of a reverse OneToOne
then something along the lines of "if not allow_many and (m2m or (not
direct and not isinstance(getattr(field,'field',None),OneToOneField))"
instead could work to allow OneToOne reverses through in setup_joins
when allow_many is False.

Regards,
Matt

-- 
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: HTTP methods in urls.py

[Matt Harasymczuk]

Then forget about ajax.*

What I am thinking is to change url dispatcher
to create three as many lists as the http methods is

GET = ()
POST = ()
DELETE = ()
...
ALL = ()

And then while parsing an urls.py it appends fitting matches to those
lists.

When goes request, for example GET, than dispatcher lookup regexp
pattern in GET lists,
if its find, we have a hit, if not go to ALL dict, if it isn't there
throw 404

This Classed based view method is good, but you have to create one
abstract view and then inherit in all your views to do so. Unless you
want to write a lot of boilerplate code per view


--
Matt Harasymczuk
www.matt.harasymczuk.pl






On Mar 21, 8:44 am, Russell Keith-Magee 
wrote:
> On Mon, Mar 21, 2011 at 9:09 AM, haras.pl  wrote:
> > It would be nice to have possibility to distinguish a HTTP method in
> > urls.py. IMHO it would be clearer and more extensible in future for
> > example:
> >  ajax ('POST', r'/user/(?P\d+)$', 'views.view2'),
> >  ajax ('GET', r'/user/(?P\d+)$', 'views.view2'),
> >  ajax ('DELETE', r'/user/(?P\d+)$', 'views.view2'),
> ...
> > I think this is a good way of getting rid of nested ifs in each view:
>
> > if request.is_ajax:
> >  #do stuff
> > else:
> >  if request.method == "POST":
> >     #do something
> >   else:
> >     #do else
>
> > Hence my true code is almost two indents inside those boilerplate if
> > structure. Which is always the same... it takes a lot of python beauty
> > and readibility from code.
>
> While I can see where this request comes from, I agree with the triage
> review that the ticket has received -- that this isn't necessary. This
> is for three reasons:
>
>  * As noted on the ticket What you are describing can already be done
> with class-based generic views, and a class-based resource structure
> is a much better way of gathering concerns than three lines in a URL
> config file
>
>  * Even if you don't want to use class-based resources, you could
> easily generate a wrapper function to direct to subviews as required
> based on request methods:
>
> def dispatched_view(get_view=None, post_view=None):
>     def _view(request, *args, **kwargs):
>         if request.method == "POST":
>             return post_view(request, *args, *kwargs)
>         return get_view(request, *args, **kwargs)
>     return _view
>
> and then, in your urls.py:
>
> url(r'/user/(?P\d+)$', dispatched_view(GET=get_view, 
> POST=post_view))
>
> Your definition of ajax_view could be a lot more complex than that,
> including handling for the is_ajax flag, other HTTP verbs, and so on.
>
>  * Lastly, even if the previous two approaches didn't exist, the
> proposal you have made requires a pretty egregious duplication of
> regular expressions. This is both a performance hit (since you need to
> match the same regular expression pattern multiple times), as well as
> a potential source of error (since you are repeating yourself).
>
> 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 
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

[Matt Harasymczuk]

I suggest this structure:

myproject
 - apps
 - libs
 - conf
 - public
 - settings.py
 - urls.py

conf:
 - production.py
 - test.py
 - dev.py

libs:
 - all third party modules

public:
  - media
  - static
  - admin
  - django.wsgi



each app structure:
 - admin
 - backends
 - commands
 - context_processors
 - decorators
 - feeds
 - forms
 - management
 - managers
 - middleware
 - models
 - signals
 - sitemaps
 - templates
 - templatetags
 - tests
 - urls.py
 - views

most of above are unnecessary for simple project, so I suggest to add
a switch to manage.py startapp to do this.
I am suggesting that app should have directories not files...
When you develop large app (CRM) you have to write tens of models,
with overriding saves, __unicode__, Meta and custom methods it becomes
hard to read and maintain

I solve this by adding app_label to each of my models in separate
files and models/__init__.py imports all models. It works like a
charm.
I think it should be by default :}

I created skel/django/project and skel/django/app folders, where I
have this file structure
when I start project I simply copy folder, rename it, and adjust

--
Matt Harasymczuk
www.matt.harasymczuk.pl

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

secret key from file...

[Matt Harasymczuk]

I had an idea.
>From time to time I find on the Internet a django app source code with
secret_key shown.

how about creating an secret.key file next to settings.py in main
project module, which should be added by developer
to .gitignore, .hgignore or equivalent

in settings we read key from file to SECRET_KEY and we go as usual.

SECRET_KEY = open("secret.key").read()

then, a django-admin startproject should give a warning "add
secret.key to your version management system ignore file", it should
automatically put generate secret phrase to this file

what about downloading an app from the Internet

manage.py createsecret
will ask if we want to generate new secret file
if file exists, and overwrite an existing one

dajngo has to be pythonic, therefore
cat secretkey.py

SECRET_KEY = "as it goes usual"

and in settings file

from .secretkey import *


What do you think?
IMHO both this ways are good


--
Matt Harasymczuk
http://www.matt.harasymczuk.pl

-- 
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: secret key from file...

[Matt Robenolt]

What we use is a settings.cfg, which is an ini file for global 
configurations. Database settings, etc. We need to share these settings 
across different languages and parts of our application.

You can set up your ini file as such:

[secret]
key=abcdefghijklmnopqrstuvwxyz0123456789


ini files are easy to parse with the ConfigParser in Python. You can simply 
parse it in your settings.py:

import ConfigParser
config = ConfigParser.ConfigParser()
config.readfp(open('../settings.cfg'))

SECRET_KEY = config.get('secret', 'key')


-- 
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: secret key from file...

[Matt Harasymczuk]

Thats right,
there should be a secret_settings.py file with db credentials and
secret_key
also a warning that it should not be added to version control


--
Matt Harasymczuk
http://www.matt.harasymczuk.pl

On Mar 21, 5:07 pm, Kristaps Kūlis   wrote:
> "real" config should not be in version control system, only reference
> config should be stored in version control.
>
> Consider database credentials - they should not be publicly available
> / downloadable from internet and they fall in same category -
> sensitive information in settings.py .
> Memcache credentials - in many cases memcache is unprotected .
>
> I think docs should be updated to reflect sensitive settings.py
> variables, which are confidential and provide "best practices" way
> ({local|secret}_settings.py ?) for deployment :). Perhaps manage.py
> command to generate adequate strenght / randomness secret would be
> beneficial .

-- 
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: secret key from file...

[Matt Robenolt]

Why not just do an import for your custom settings?

try:
from site_settings import *
except ImportError:
pass


On Mar 22, 2011, at 5:51 PM, Ian Kelly wrote:

> On Tue, Mar 22, 2011 at 6:44 AM, Kristaps Kūlis
>  wrote:
>>  I personally would greatly appreciate update in docs to show "best
>> way" to handle per enviroment settings / sensitive settings, as now
>> there is many ways :)
>>  Consider when one has his local development enviroment with locmem
>> cache and sqlite3 db, and staging server with MySQL / memcache and
>> production cluster with MySQL (different credentials) and memcache
>> cluster. In settings.py most deployment  specific stuff is left blank
>> and on deployment {staging/production}_settings.py is created with
>> from settings import * and then overriding per env settings :).
>>  Actually it took me far too much googling to find "how" and "what" to
>> do, at least I believe that such stuff should be put in docs to make
>> django more sysadmin friendly.
> 
> I don't know what the best way is, but I will share what we do.  In
> addition to the regular settings.py we have site_settings.py (which is
> not under version control) in the same directory.  Then at the end of
> settings.py we add this simple code:
> 
> # Run a separate python file not in version control for database
> # settings and other sensitive information.
> from os.path import dirname, join
> execfile(join(dirname(__file__), 'site_settings.py'))
> 
> Cheers,
> Ian
> 
> -- 
> 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.
> 

-- 
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: secret key from file...

[Matt Robenolt]

That's just interesting. I've never seen the use of `execfile()` before. We use 
a devsettings.py and use it to override an individual server or local settings, 
and then on the live/deployed server, no devsettings.py is even included. Hence 
the try...except wrapped around it. It's a nice little pattern that gets us by, 
but yes, things like this do show that there needs to be one overall 
"recommended" method for maintaining separate settings on a per 
server/environment basis.

On Mar 22, 2011, at 7:05 PM, Ian Kelly wrote:

> On Tue, Mar 22, 2011 at 4:49 PM, Matt Robenolt
>  wrote:
>> Why not just do an import for your custom settings?
>> 
>> try:
>>from site_settings import *
>> except ImportError:
>>pass
> 
> No particularly compelling reason that I know of, the import machinery
> is just unnecessary in this case.  The site_settings.py is viewed as
> an extension of the settings.py, so it doesn't need to be loaded as a
> module in its own right.  And for the same reason we know exactly
> where we expect the file to be, so there's no need to consult
> sys.path.
> 
> I suppose it just comes down to a matter of taste.
> 
> Cheers,
> Ian
> 
> -- 
> 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.
> 

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

MEDIA, STATICFILES and ADMIN to dictionaries like CACHES and DATABASES

[Matt Harasymczuk]

I give you an example:

BTW switch name from media to "useruploaded" or "uploaded", which IMHO
is self explaining, hence MEDIA is not.

STATICFILES = {
  'uploaded' : { # old name MEDIA
 'PREFIX' : '',
 'ROOT': '',
 'URL': '',
  },
  'admin': {
 'PREFIX' : '',
 'ROOT': '',
 'URL': '',
  },
  'static': {
 'PREFIX' : '',
 'ROOT': '',
 'URL': '',
  }
}

-- 
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: Django urls in JavaScript

[Matt Robenolt]

How could this even begin to be solved without incurring another http 
request to resolve the url pattern?

The only way I can imagine it is if we had a generic /resolve/ path that 
took some get parameters to return a full URL, or even it translate to a 301 
redirect, but that'll get messy with POSTs.

-- 
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: Django urls in JavaScript

[Matt Robenolt]

So you're basically proposing to write a Javascript library that is a 
translation of URLResolver, and essentially have a dynamic "Javascript" file 
that could be included that would contain your URL patterns? Just trying to 
make sure we're on the same page.

-- 
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: Django urls in JavaScript

[Matt Robenolt]

There also proposes the problem of selecting which urls are "published" in 
this file and which aren't. Any ideas for that? I'm sure lots of people 
wouldn't want their entire sitemap exposed to the public in one large js 
file.

-- 
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: Django urls in JavaScript

[Matt Robenolt]

I think the biggest problem with translating the reverse() lookup is the 
lack of kwargs and named capture groups in Javascript regex. So a pattern 
such as: /page/(?P\d+)/ would not translate whatsoever. Then on the 
Javascript side, we wouldn't be able to use:  reverse('goto_page', [], 
{page_id: 5});  It would have nowhere to map up the page_id variable to. We 
could probably get away with some sort of pseudo regex rules in Javascript.

-- 
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: Django urls in JavaScript

[Matt Robenolt]

It could just be a combo of both. There'd be one file for the 
urlresolver.js, and a patterns.js. Interesting.

Now, could the patterns in Python be translated to Javascript properly? I'll 
do some playing around today and see if I can come up with some basics. Even 
if this doesn't land in Django core, it could be a nice library.

-- 
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: Django urls in JavaScript

[Matt Robenolt]

Ahh, I missed that from your original post.

I like that. :)

-- 
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: Proposal: switch to HTML5 for bundled templates

[Matt Harasymczuk]

How about delivering http://www.modernizr.com/ library.
In my case it solves all problems with non existing tags (nav,
section, header, article, footer) in such browsers as IE.

We ship jQuery with admin, why not use modernizr to support legacy
browsers.

I am positive, about input types fallback to text.
I have tested this for a long time and it works.

Generally speaking converting contrib apps to html5 would be a very
good idea! Most django deployments does not depend on whether it has
html4 or 5.
Those who stick with 4, should have the same functionality provided by
fallback in their browsers, however the largest part of the remaining
group should benefit from transition.

Google dropped support for IE6 legacy browsers more than year ago!
http://googleenterprise.blogspot.com/2010/01/modern-browsers-for-modern-applications.html

Even microsoft wants IE6 dead
http://ie6countdown.com/

I think we should join this movement, and provide modernizr, for
example in conditional css tag


It works for me, hence all should benefit from it.


--
Matt Harasymczuk
http://www.matt.harasymczuk.pl

-- 
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: Proposal: switch to HTML5 for bundled templates

[Matt Harasymczuk]

Maybe start thinking in other way.

Most of users has JS enabled browsers, if so, modernizr works.
Otherwise jQuery will not work either.

I can't remember when someone who has IE6 hit one of my django based
sites.

Maybe convert django to html5, and those who has to care about ie6
support should overwrite doctypes in templates and think about special
widgets. Give them {% block doctype %}{% endblock %}.

As far as I know ie6 won't recognize difference if there is doctype
specified, it is specified invalid, or there is none. Therefore it
should not crash.

Probably for 1 developer who needs to support ie6, there is 20 who
does not need to.
For me, this situation is like minority terrorizing the whole nation.

Overwriting admin templates is easy, providing widgets to fallback
html5 input types to text fields seems not to be complicated.

Consider this:

from django.forms.widgets_legacy import *

and we're free to go, providing support for forgotten browsers.

Google on its search main page is using , hence IMHO it
is nothing wrong with doctype.

BTW. Who is using proper mimetype with current django doctype in
cotrib admin?

I think that sticking with support for browser that even its creator
wants to die is wrong.
Django should go further and further, not stay in one place, because
of support for legacy features.

Django 1.3 is good, even very good, if someone wants to create django
based webapp with support ie6, should stick to 1.3 version.
Therefore 1.4 should have one of key feature: render with html5 by
default.

BTW. whatwg dropped from HTML5 its 5 in the name
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024477.html
In that case IE6 is not HTML complaint and browser specific hacks
should not be a official and main part of framework.

There should be point of no return for this. And I think that 1.3 is
very good release to end support for legacy browsers.
Otherwise why not to support lynx and table based design?
I use terminal browsers from time to time. I think it is even more
important, because google bot which greatly influence on our potential
revenue sees pages like lynx does.

If not support html5 features now before the 1.4 release, then mark
support for ie6 like the XMLField, obsolete and on an accelerated
deprecation schedule.

I rest my case ;}

--
Matt Harasymczuk
http://www.matt.harasymczuk.pl

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

Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name" (repost)

[Matt Hoskins]

My apologies for reposting this - I originally posted this at the end
of January and as soon as I posted it I realised that with the push
for bug squashing for the 1.3 release going on I probably wouldn't get
any attention (and thus comment or replies :), so I'm trying a repost
now that 1.3 is out. If someone knowledgeable about the query code in
django could comment on whether the behaviour is by design or an
oversight that would be useful!

(Below where I say "reverse name" I mean using that reverse name from
the model that the OneToOneField relates to)
-
Working on some code I've hit that the reverse name for a
OneToOneField cannot be used, it seems, in values_list or values. I
couldn't see why there would need to be such an exclusion, given it is
a one-to-one relationship, so am wondering if it's just an oversight
in the code or a deliberate exclusion?

The portion of code that is rejecting doing e.g.
"values_list('onetoonereversename')" is in setup_joins where the if
line reads:

if not allow_many and (m2m or not direct):

The values of "m2m" and "direct" come from opts.get_field_by_name and
it seems that the reverse of a OneToOne gives the same results as the
reverse of a ForeignKey, as of course both are not m2m and are not
direct. Looking at the code later on in setup_joins it describes the
path where direct is false and m2m is false as being "One-to-many
field (ForeignKey defined on the target model)", so it looks like the
logic I've quoted above of "if not allow_many and (m2m or not direct)"
has the "not direct" clause in to reject reverse ForeignKey
relationships and in doing so also rejects reverse OneToOne
relationships (and with the latter case I suspect it need not!).

If someone a bit more knowledgeable about the query machinery could
comment on whether it does look like an oversight or is a deliberate
exclusion, then if it's the former I'll log it as a bug.

Assuming the rest of the code is ok in the case of a reverse OneToOne
then something along the lines of "if not allow_many and (m2m or (not
direct and not isinstance(getattr(field,'field',None),OneToOneField))"
instead could work to allow OneToOne reverses through in setup_joins
when allow_many is False.

Regards,
Matt

-- 
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: Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name" (repost)

[Matt Hoskins]

On Apr 7, 8:59 am, Russell Keith-Magee 
wrote:
>
> I'd need to go spelunking through the code to be sure, but if this is
> happening, I'd be guessing it's oversight. From a quick scan of the
> test suite, I can't find an obvious test for values() on one-to-one
> fields.
>
> As for the reason for this; OneToOne keys are a degenerate case of
> foreign key, but in the reverse direction, they have a single value
> (as opposed to the multiple values of a reverse foreign key). As a
> result, the oversight would be failing to include reverse one-to-ones
> in the list of valid names, overriding the default interpretation for
> the ForeignKey from which they are inherited.
>
> So - it sounds like this should be reported as a ticket; If you could
> also reduce this to a test case that is integrated into Django's test
> suite (regressiontests/one_to_one_regress would be a good place,
> because it has o2o models ready to use), that would be very helpful.
>
> Yours,
> Russ Magee %-)

Hi Russ,

Thanks for taking a look at this. I knocked up a quick test case and
was surprised to find that it passed under Django 1.3 (I hadn't tried
testing under 1.3 before, but I'd checked the two sections of code in
1.3 that relate to the problem being triggered and they hadn't changed
so I was fairly sure it hadn't been directly fixed!).

After much rummaging around I eventually found that #5768
http://code.djangoproject.com/ticket/5768 has removed the restriction
on M2M being used in .values and .values_list (i.e. the call to
self.query.add_fields changed to say m2m were allowed) so the fact
that setup_joins is treating a reverse OneToOne the same as a reverse
ForeignKey (i.e. it's potentially many to many in nature) doesn't lead
to the exception being raised any more.

So alas if I log the bug and supply a test then the test will pass :).
It may not matter that the oversight I outlined exists if it can't
manifest as a problem now - although I suspect it's useful to have a
regression test on values() and values_list() referencing the reverse
of O2O in case of future changes. A test that does a deeper call to
queryset.query.add_fields() with allow_m2m set to False could be
written, but I guess that's a no-no as it's testing the implementation
rather than the public API.

Want me to log it as a bug and include the test that'll pass and some
notes explaining what's gone on? (I can, and have, run the same test
against Django 1.2.5 to prove the test fails where the problem hasn't
been masked by the change to the call to add_fields).

Regards,
Matt

-- 
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: Using OneToOneField in reverse from values or values_list is rejected with "Invalid field name" (repost)

[Matt Hoskins]

On Apr 7, 10:47 am, Julien Phalip  wrote:

> Hi Matt,
>
> Do you think this could be related 
> tohttp://code.djangoproject.com/ticket/11448
> ?
>
> If so, do the patches attached to that ticket help resolve your issue?
>
> Thanks,
>
> Julien

Hi Julien,

Thanks for your reply - from a quick squint at that ticket I don't
think it's related (options._name_map was populated with current
information, it's just that map doesn't have sufficient information to
allow setup_joins to differentiate between the reverse of O2O and the
reverse of ForeignKey). As you can see from a reply I've just made to
Russ I think the problem has gone away in Django 1.3 anyway (or at
least it's been masked by another change, so I can now use reverse O2O
in values and values_list with 1.3 without getting an error).

Regards,
Matt

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

I don't think #15289 has been fully fixed

[Matt Hoskins]

I'm just going through some code in an application and adjusting it to
work with Django 1.3 and I thought I'd have to fix a portion of code
to account for the change in transactions meaning that a
cursor.execute call would leave a transaction in a dirty state (even
tho' it didn't change anything). I was surprised to find on the
development server that no error was raised.

Looking into the code, I don't think http://code.djangoproject.com/ticket/15289
has been fully fixed... Because CursorDebugWrapper defines its own
execute and executemany methods then calls in debug mode to
cursor.execute() and cursor.executemany() will not leave the
transaction dirty if it's managed (because __getattr__ won't be called
for those two methods).

I'm also a bit perplexed actually by the bit in
CursorWrapper.__getattr__  that looks in self.__dict__ - maybe my
python knowledge is a bit rusty, but if the attr was already in
self.__dict__ then surely __getattr__ would not get called (the only
time this wouldn't be the case would be if it wasn't there at the
start of the call to __getattr__ but something else put it in there,
however the calls to self.db methods won't do that)?

The two choices I see are: First is to add the two lines to each of
the two methods in CursorDebugWrapper to set the dirty flag when
appropriate (and remove the redundant bit of code about self.__dict__
from __getattr__, assuming I'm right about that!). Second is to
replace __getattr__ with __getattribute__ such that truly any
attribute access on a wrapped cursor, including subclasses, will go
through the dirty flag setting, although more care is needed if that
is done because you can't even access self.__dict__ directly without
__getattribute__ going off - a call has to be made to the
object.__getattribute__ - so self.db and self.cursor would need to be
fished out using that.

I wasn't sure about reopening #15289 or raising a new ticket, so
thought I'd post here to ask about the best course of action (assuming
I'm spot on in my assessment of the situation).

Regards,
Matt

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

Logging configuration and handle_uncaught_exception

[Matt Bennett]

For the background to this problem please see my Stack Overflow
question here [1].

I recently had to do some head-scratching over Django 1.3's logging
configuration, because with DEBUG=True the 'django.request' logger
isn't called when an uncaught exception occurs during a request.

It wasn't obvious at all to me that 500 errors are only processed by
the logger when not in debug mode. This behaviour made sense when the
only error processing was to send an email to the site admins, but now
we're free to add more handlers to the logger and may want some of
them to be enabled in development as well as in production.

Is there a reason the call to logger.error can't come before we return
the technical_500_response when DEBUG=True? It seems to me that the
debug level should be checked in each individual handler, rather than
determining whether the error is passed to the logger at all.

Regards,
Matt.


[1] 
http://stackoverflow.com/questions/6305132/django-1-3-logging-500-errors-are-not-logged

-- 
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: Logging configuration and handle_uncaught_exception

[Matt Bennett]

On Mon, Jun 13, 2011 at 9:53 PM, Vinay Sajip  wrote:
> On Jun 10, 2:05 pm, Matt Bennett  wrote:
>
>> Is there a reason the call to logger.error can't come before we return
>> the technical_500_response when DEBUG=True? It seems to me that the
>> debug level should be checked in each individual handler, rather than
>> determining whether the error is passed to the logger at all.
>
> Aren't these two separate things? It makes sense to have the logging
> of errors occur in all code paths, but that isn't connected with
> levels on handlers. The first requires the logging call to be added to
> the code, whereas levels on handlers can be configured to be as
> verbose (or not) as you like, independently of logging calls in the
> code.
>

I think we're saying the same thing - my point is that the logging of
errors should occur in call code paths. Currently, an unhandled view
error is *not* logged if settings.DEBUG is True. To be clear, this has
nothing to do with the log levels on the handlers.

I've attached a patch which modifies
django.core.handlers.base.handle_uncaught_exception to log the error,
and stops AdminEmailHandler sending email if settings.DEBUG is True.
Hopefully this makes it clear what I was proposing above.

Curiously, the modification to AdminEmailHandler causes several tests
in regressiontests.views to fail. The tests that fail are trying to
validate that the contents of emails sent conform to the various
configured settings, and they expect email to be sent even if
settings.DEBUG is True - which isn't what happens when django
processes a real view.

For my patch to pass, I could simply drop the modification to
AdminEmailHandler, or update the tests so that email is not expected
if settings.DEBUG is True (which arguably should be changed anyway).

Matt.




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

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



debug-logging.diff
Description: Binary data

Re: Logging configuration and handle_uncaught_exception

[Matt Bennett]

> This is a case for a custom Filter object [1]. The filter object
> implementation would only be a few lines, to reject logging when DEBUG
> is True, and can be attached to the admin email handler in the default
> logging configuration. [2] This way the logging call can occur in all
> code paths, and the admin email handler itself can remain
> general-purpose, but the backwards-compatible behavior can be maintained.
>
> Matt, if you'd be willing to open a ticket for this, that'd be helpful.
> If you feel like putting together a patch using the Filter approach,
> that'd be even better ;-)

Here you are: https://code.djangoproject.com/ticket/16288

Since logging Filters are not specific to an individual logger or
handler, I've just called it DebugFalseFilter. It's not a pretty name,
but I couldn't come up with anything better - I decided it should
convey what the filter allows through, but AFAIK there's no name for
"not debug mode".

Matt.

-- 
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: Logging configuration and handle_uncaught_exception

[Matt Bennett]

On Fri, Jun 17, 2011 at 6:45 PM, Vinay Sajip  wrote:
> Matt Bennett  writes:
>
>>
>> > This is a case for a custom Filter object [1]. The filter object
>> > implementation would only be a few lines, to reject logging when DEBUG
>> > is True, and can be attached to the admin email handler in the default
>> > logging configuration. [2] This way the logging call can occur in all
>> > code paths, and the admin email handler itself can remain
>> > general-purpose, but the backwards-compatible behavior can be maintained.
>> >
>> > Matt, if you'd be willing to open a ticket for this, that'd be helpful.
>> > If you feel like putting together a patch using the Filter approach,
>> > that'd be even better
>>
>> Here you are: https://code.djangoproject.com/ticket/16288
>>
>> Since logging Filters are not specific to an individual logger or
>> handler, I've just called it DebugFalseFilter. It's not a pretty name,
>> but I couldn't come up with anything better - I decided it should
>> convey what the filter allows through, but AFAIK there's no name for
>> "not debug mode".
>
> Reposting this, after Google swallowed my earlier response. Sorry if it
> eventually turns up, making this a double post ...
>
> A more general solution would be something like this:
>
> class ConditionFilter(logging.Filter):
>    def __init__(self, condition):
>        self.condition = condition
>
>    def filter(self, record):
>        return self.condition
>
> which you can then use in the logging configuration using something like
>
> 'require_debug_false': {
>    '()': 'django.utils.log.ConditionFilter',
>    'condition': not DEBUG,
> }
>
> This will allow the filter to be used in more places, e.g. you could use a 
> more
> complex settings-time condition.
>
> Regards,
>
> Vinay Sajip
>

+1. Perhaps the reason I don't like DebugFalseFilter as a name is that
it's so specific.

-- 
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: RFC: Django 1.0 roadmap and timeline

[Matt Davies]

Jacob, I feel your pain butty.

Do what you think is right, django has been brilliant so far.

The jump to version 1(lightspeed) has been a bit of a nightmare, but let's
all remember a pre django world.

I for one trust Jacob's judgement.

Just do it mate, there's good good people who want to help.

Chewie fixed the falcon with a blow from a spanner.

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

rev 7920 fresh checkout fails tests?

[Matt Wilson]

I'm trying to figure out if I'm running the tests incorrectly, or if
there are really are failed tests in the revision.

There's no point in working on a patch if I'm just doing something
wrong, so I'd really appreciate it if somebody can look over how  I'm
running these tests.

I ran the runtests.py script with this settings.py:

$ cat tests/settings.py
DATABASE_ENGINE = 'sqlite3'
DATABASE_NAME = 'demodb'
ROOT_URLCONF=None

I ran the tests like this, and got two failures:

$ python runtests.py --settings settings
==
FAIL: Doctest: regressiontests.utils.tests.__test__.itercompat
--
Traceback (most recent call last):
  File "/home/matt/virtualenvs/django-scheduler/lib/python2.5/site-
packages/django/test/_doctest.py", line 2180, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
regressiontests.utils.tests.__test__.itercompat
  File "/home/matt/svn-checkouts/django/tests/regressiontests/utils/
tests.py", line 0, in itercompat

--
File "/home/matt/svn-checkouts/django/tests/regressiontests/utils/
tests.py", line 4, in regressiontests.utils.tests.__test__.itercompat
Failed example:
from django.utils.itercompat import sorted as compat_sorted
Exception raised:
Traceback (most recent call last):
  File "/home/matt/virtualenvs/django-scheduler/lib/python2.5/site-
packages/django/test/_doctest.py", line 1267, in __run
compileflags, 1) in test.globs
  File "", line 1, in

from django.utils.itercompat import sorted as compat_sorted
ImportError: cannot import name sorted
--
File "/home/matt/svn-checkouts/django/tests/regressiontests/utils/
tests.py", line 8, in regressiontests.utils.tests.__test__.itercompat
Failed example:
y = compat_sorted(x)
Exception raised:
Traceback (most recent call last):
  File "/home/matt/virtualenvs/django-scheduler/lib/python2.5/site-
packages/django/test/_doctest.py", line 1267, in __run
compileflags, 1) in test.globs
  File "", line 1, in

y = compat_sorted(x)
NameError: name 'compat_sorted' is not defined
--
File "/home/matt/svn-checkouts/django/tests/regressiontests/utils/
tests.py", line 9, in regressiontests.utils.tests.__test__.itercompat
Failed example:
print y
Exception raised:
Traceback (most recent call last):
  File "/home/matt/virtualenvs/django-scheduler/lib/python2.5/site-
packages/django/test/_doctest.py", line 1267, in __run
compileflags, 1) in test.globs
  File "", line 1, in

print y
NameError: name 'y' is not defined


==
FAIL: Doctest: regressiontests.queries.models.__test__.API_TESTS
--
Traceback (most recent call last):
  File "/home/matt/virtualenvs/django-scheduler/lib/python2.5/site-
packages/django/test/_doctest.py", line 2180, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
regressiontests.queries.models.__test__.API_TESTS
  File "/home/matt/svn-checkouts/django/tests/regressiontests/queries/
models.py", line unknown line number, in API_TESTS

--
File "/home/matt/svn-checkouts/django/tests/regressiontests/queries/
models.py", line ?, in
regressiontests.queries.models.__test__.API_TESTS
Failed example:
Item.objects.filter(created__in=[time1, time2])
Expected:
[, ]
Got:
[]
--
File "/home/matt/svn-checkouts/django/tests/regressiontests/queries/
models.py", line ?, in
regressiontests.queries.models.__test__.API_TESTS
Failed example:
Item.objects.all()[0:0]
Expected:
[]
Got:
[, , , ]


--
Ran 363 tests in 205.490s

FAILED (failures=2)

--~--~-~--~~~---~--~~
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: rev 7920 fresh checkout fails tests?

[Matt Wilson]

On Jul 13, 11:50 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Looking at the failures you are getting, it looks like you might not
> have a completely clean checkout. At least some of the failures appear
> to be due to the recently added python 2.3 compatibility
> implementation of sorted(), and the tests of that function.

I figured the problem and it was in my setup.  I'm using virtualenv,
and I forgot to rerun python setup.py install after I checked out
7920.  So, the installed version of django was an older revision, and
itercompat.sorted wasn't defined.

Whoops!

Thanks to everyone for the help.

Matt
--~--~-~--~~~---~--~~
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: Results of Moscow local sprint (newforms-admin and Oracle pooling)

[Matt Boersma]

That's pretty cool!  I've attempted this in the past, but always ended
up with test case failures, and didn't see any speedups, so I
abandoned it.  I'll try this out when I have time.

Could someone repackage it as a proper patch attached to ticket #7732?

I think I'd rather see it folded into the trunk for the Oracle
backend, rather than as a separate backend.  We require cx_Oracle
4.3.1 or later, so there shouldn't be any issues with pooling support.
 But I suppose that relegates this to post-1.0.

Matt

On Jul 15, 2:38 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> 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!
>
> Nonetheless... We worked on a few bugs which all tagged with the keyword
> "yandex-sprint"[1]. Many thanks to Honza Král who was on #django-sprint
> that day and promptly triaged our tickets. Now I'd like to ask someone
> of committers to take a look at them.
>
> One ticket deserves a special note. There were 3 guys who were working
> not on newforms-admin bugs but on a new Oracle backend with support for
> pooling connections. They did finish it and submitted it in Trac[2]. The
> ticket already has a note about repackaging the backend as a patch.
> However I think it worse to ask opinion of guys that support the
> official Oracle backend on what's better to do with this code: make it
> another backend, make it an external backend, replace current backend?
>
> Thanks!
>
> [1]:http://code.djangoproject.com/query?keywords=~yandex-sprint&order=pri...
> [2]:http://code.djangoproject.com/ticket/7732
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

You've broken Oracle

[Matt Boersma]

This is just a heads up since clearly some committers must be unaware:
checkins of the last two days have created 27 (yes, twenty-seven) new
test case failures for Oracle.  I had been working on cleaning up the
existing few failures for the Oracle backend, but unless those who
actually committed the weekend's changes are able to look at this,
Oracle should not be included in the 1.0 release IMHO.

I realize running all the backends (and all three pythons) to check
for regression failures before committing code is onerous.  However,
that's what I do, and now I'm reminded why.  It's not enough to see
that the code runs on sqlite or postgres and call it a day.

Here is Leo Soto's buildbot, so you can see what I'm talking about:
http://certenium.ingenium.cl:8080/hudson/job/django-trunk/

I'll do my best to fix some of these as time permits, but I'm hoping
others will pull together to rectify this quickly.  Thanks!
--~--~-~--~~~---~--~~
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: You've broken Oracle

[Matt Boersma]

Thanks very much for the pointer, Ramiro.  It was indeed changes to
the "extra_select" QS param that caused Oracle problems, and I've
taken a similar approach to yours in fixing it.

Rather than flag "row_number()" as an extra_select parameter (and then
try to clean up after it later), Oracle now just uses the default
set_limits and clear_limits methods and does all extra query munging
in its as_sql() method.  And instead of doing an outer SELECT *, we
SELECT specific columns (or aliases) by name and ignore our
row_number() column, which is only used in the WHERE clause.

This seems to fix most of the failures.  I'll check it in soon when
I'm sure it's not causing any new problems.

On Aug 18, 2:20 pm, "Ramiro Morales" <[EMAIL PROTECTED]> wrote:
> Matt,
>
> On Mon, Aug 18, 2008 at 4:04 PM, Matt Boersma <[EMAIL PROTECTED]> wrote:
>
> > Here is Leo Soto's buildbot, so you can see what I'm talking about:
> >http://certenium.ingenium.cl:8080/hudson/job/django-trunk/
>
> > I'll do my best to fix some of these as time permits, but I'm hoping
> > others will pull together to rectify this quickly.  Thanks!
>
> Some of these failures might be related to the changes in the `extra_select`
> (and `extra_select_params` that got deleted) Query class attributes introduced
> in r8426 because, as you know, the Oracle backend (and the MS SQL Server
> backends) uses `extra_select` to insert a synthetic placeholder needed to use
> the ORDER_BY function to emulate LIMIT+OFFSET.
>
> FWIW, in my work on a MS SQL Server backed I circumvented the bulk of the
> problem by accident (actually, because this is one of the things that allowed
> me to get a whole bunch of the Django test suite to start passing on SQL
> Server 2005 whose SQL dialect also has the ORDER_BY function) some time ago by
> migrating away from using `extra_select` to using the `ordering_aliases`
> attribute to handle the placeholder by appending to it:
>
> http://code.google.com/p/django-pyodbc/source/browse/branches/ramiro/...
>
> Later on during the lifetime of the query, the `execute_sql()` Query method
> will take care of ignoring that alias.
>
> This also allowed me to do away with the `set_limits()` and `clear_limit()`
> custom Query class methods.
>
> I don't know if this is also possible for the Oracle backend, hopefully it is.
>
> HTH,
>
> --
>  Ramiro Morales
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---