Re: Is this true. that django really takes a lot of memory?

[Jeremy Dunck]

On Tue, Feb 17, 2009 at 3:52 PM, James Bennett  wrote:
>
> On Tue, Feb 17, 2009 at 7:40 AM, NitinHayaran  wrote:
>> Today i read this article and was wondering whether django orm is
>> really that bad.
>>
>> http://dayhacker.blogspot.com/2009/02/why-django-orm-sucks-it-takes-hell-lot.html
>
> Well, it's obligatory for me first to say "wow, Blogger sucks", since
> I can't actually read that post -- I just get a Blogger template with
> a big white empty space where the article ought to be (looking even at
> the HTML source, the content just ain't there).

It used to be there.  I think the OP deleted the post.

--~--~-~--~~~---~--~~
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: Is this true. that django really takes a lot of memory?

[Jeremy Dunck]

On Tue, Feb 17, 2009 at 6:49 PM, Malcolm Tredinnick
 wrote:
...
> I'd be somewhat against this, I think. It's *very* easy to reuse
> querysets and inadvertently cause extra database queries.
...
> we're trading memory
> usage for speed and ease of use (and providing a way to improve the
> former in "expert mode").

Point taken.

I wish there were some way to issue a warning if _result_cache is
filled but __iter__ isn't used more than once.  :-/

I could imagine a warning being issued if the functionality offered by
.iterator is used more than once.  That might be a happy medium-- then
I could use .iterator as my default coding practice, and be slapped
when I iterate more than once after all.

if settings.DEBUG and self.prior_iteration:
   warnings.warn("dope!")
?

--~--~-~--~~~---~--~~
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: Is this true. that django really takes a lot of memory?

[Jeremy Dunck]

On Tue, Feb 17, 2009 at 7:13 PM, Malcolm Tredinnick
 wrote:
...
>> if settings.DEBUG and self.prior_iteration:
>>warnings.warn("dope!")
>
> This certainly sounds reasonable and doable today without any real
> overhead. Go ahead and make a patch/ticket.

OK.

Do you think there should be a PerformanceWarning class, or just use
the default UserWarning?

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

TransactionMiddleware and cursor.execute

[Jeremy Dunck]

The Django docs for TransactionMiddleware state:
"When a request starts, Django starts a transaction. If the response
is produced without problems, Django commits any pending
transactions."

This is apparently not actually true.

I have some code using cursor.execute while doing no operations using
the ORM through a full request cycle-- but it does run under
TransactionMiddleware.  It turns out that if transaction.set_dirty
never gets called, then the request completes without a commit going
to the DB; the DB rightfully interprets this as a rollback.

This caused silent data loss for about a year for me; it wasn't
obvious for some time because my .execute call often coincides with
other ORM use, meaning that a large portion of the data I meant to
save actually did get saved.

I would like basically any data going to the DB to trigger set_dirty.
I *think* this just means cursor.execute with insert/update/delete,
but I haven't reviewed closely yet.

Is there any objection to this change?  I can work up a patch, but
this is obviously a touchy area.

--~--~-~--~~~---~--~~
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: TransactionMiddleware and cursor.execute

[Jeremy Dunck]

On Fri, Mar 6, 2009 at 9:34 AM, Karen Tracey <kmtra...@gmail.com> wrote:
> On Fri, Mar 6, 2009 at 10:28 AM, Jeremy Dunck <jdu...@gmail.com> wrote:
>>
>> The Django docs for TransactionMiddleware state:
>> "When a request starts, Django starts a transaction. If the response
>> is produced without problems, Django commits any pending
>> transactions."
>>
>> This is apparently not actually true.
...
> Sounds like:
>
> http://code.djangoproject.com/ticket/9964

Right you are, thanks for the pointer.

--~--~-~--~~~---~--~~
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: Cache related values without needing to hit database twice

[Jeremy Dunck]

On Tue, Mar 10, 2009 at 11:12 AM, Vinicius Mendes  wrote:
...
> What do you think in saving the author value in the blog instance if it is
> achieved through the author instance? It's something like telling blog who
> is his author in the moment you are retrieving it from the author.

You're describing ye olde #17:
http://code.djangoproject.com/ticket/17

--~--~-~--~~~---~--~~
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: IPy for settings.INTERNAL_IPS

[Jeremy Dunck]

On Sat, Mar 14, 2009 at 6:33 PM, Rodrigo Guzman  wrote:
...
> So, it seems like it'd be a straight forward change to
> django.core.context_processors.debug to implement it.  However, it
> seems that this functionality would be better placed in the settings
> module.

Django only uses INTERNAL_IPS using "in", so just __contains__ is needed.

I've been doing something like this in my project settings for some
time; unless I'm missing something, there's no need to change Django:

class CIDR_LIST(list):
def __init__(self, cidrs):
from IPy import IP
self.cidrs = []
try:
for cidr in cidrs:
self.cidrs.append(IP(cidr))
except ImportError:
pass
def __contains__(self, ip):
try:
for cidr in self.cidrs:
if ip in cidr:
return True
except:
pass
return False

INTERNAL_IPS = CIDR_LIST([
'127.0.0.1/32',
'10.0.0.0/24'
])

--~--~-~--~~~---~--~~
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: IPy for settings.INTERNAL_IPS

[Jeremy Dunck]

On Sat, Mar 14, 2009 at 11:05 PM, Alex Gaynor  wrote:
...
> Why are you subclassing list if you're going to just add a cidrs attr that's
> the list :)

I'm handling INTERNAL_IPS which are multiple CIDR blocks.  I could
have constructed with [IP('...'),IP('...')], but that's tomayto
tomahto.  __contains__ loops over the multiple CIDRs-- is there a
better way?

--~--~-~--~~~---~--~~
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: IPy for settings.INTERNAL_IPS

[Jeremy Dunck]

Yeah, dumb bug. :)



On Mar 15, 2009, at 4:12 PM, Ludvig Ericson <ludvig.eric...@gmail.com>  
wrote:

>
> On Mar 15, 2009, at 05:02, Jeremy Dunck wrote:
>
>> class CIDR_LIST(list):
>>   def __init__(self, cidrs):
>>   from IPy import IP
>>   self.cidrs = []
>>   try:
>>   for cidr in cidrs:
>>   self.cidrs.append(IP(cidr))
>>   except ImportError:
>>   pass
>>   def __contains__(self, ip):
>>   try:
>>   for cidr in self.cidrs:
>>   if ip in cidr:
>>   return True
>>   except:
>>   pass
>>   return False
>
>
> from IPy import IP
>
> class CIDRList(list):
>def __init__(self, seq=()):
>super(CIDRList, self).__init__(map(IP, seq))
>
>def __contains__(self, other):
>return any(other in range for range in self)
>
> Of course, any only exists in recent Pythons, same for generator
> expressions.
>
> I also question the `except ImportError` in your __init__. :-)
>
> - Ludvig
>
> >

--~--~-~--~~~---~--~~
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: Reminder: Django 1.1 beta this week means feature freeze

[Jeremy Dunck]

On Thu, Mar 19, 2009 at 4:20 PM, Jacob Kaplan-Moss
 wrote:
...
>
> /me looks meaningfully at Justin.

FWIW, I've been a terrible contributor on GIS.  All praise to Justin's
great work.

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

Dynamic urlconf

[Jeremy Dunck]

I have a need for dynamic URL definition, but I see that
RegexURLResolver.reverse uses a cache, _reverse_dict.

Option 1):
   Make a RegexURLResolver subclass which sets _reverse_dict back to
an empty MultiValueDict when a URL is added or removed
Option 2)
   Make me do it in my app ;-)

Which do you prefer?

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

Deletion of related objects

[Jeremy Dunck]

Malcolm, Jacob pointed me at you, since the code in question was a
commit around QSRF-time.

I'm aware of ticket #7539, but would prefer to keep the scope narrower
and ask the hopefully-useful question-- is #9308 a bug?  If so, I'd
like to close it for 1.1.

In summary, #9308 describes a situation where B has a nullable FK to
A, and an instance of A is being deleted.   Currently, any B's related
to A also get deleted.

#9308 takes the position that any B.a_id's should be set to null
rather than B instances being removed along with the desired deletion
of A.   I'm asking explicitly whether this is is a bug?

Commit [8128] added some code which looks vaguely related, with the
commit message:
"Fixed #7853 -- Fixed another case of deleting inherited models with
foreign key references. Thanks to Russell for the test case that
demonstrated the problem."

There's a patch now which alters that code, but I'm not convinced it's
fixing anything.  This area is fairly lightly tested:
http://code.djangoproject.com/browser/django/trunk/tests/modeltests/delete/models.py?rev=8030#L36

Thoughts?

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

Dallas 1.1 sprint - dates?

[Jeremy Dunck]

Hey all, I was considering putting on a Dallas sprint for 1.1.  I'm
not sure exactly when 1.1 will ship, but soon-ish, so I was thinking
about trying to make the sprint the weekend of 4/10 (Easter weeked) or
4/17.

Any preference?  Who can make it or will consider making it?

--~--~-~--~~~---~--~~
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: Dallas 1.1 sprint - dates?

[Jeremy Dunck]

Gary, Justin?

On Fri, Apr 3, 2009 at 9:47 AM, Alex Robbins
<alexander.j.robb...@gmail.com> wrote:
>
> I live in the Dallas area and would be interested in coming, whenever
> it happens.
>
> On Apr 2, 12:45 pm, Jeremy Dunck <jdu...@gmail.com> wrote:
>> Hey all, I was considering putting on a Dallas sprint for 1.1.  I'm
>> not sure exactly when 1.1 will ship, but soon-ish, so I was thinking
>> about trying to make the sprint the weekend of 4/10 (Easter weeked) or
>> 4/17.
>>
>> Any preference?  Who can make it or will consider making it?
> >
>

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

Dallas Django sprint 4/18 - 4/19 at CoHabitat

[Jeremy Dunck]

We've firmed up the Dallas Django sprint plans:

Django 1.1 is around the corner, but there are lots of bugs left to
squash. Come meet the other Django people around Dallas and check out
Cohabitat, the great coworking spot in uptown.

We'll start Saturday, April 18, 2009 at 9:00am through Sunday, April
19, 2009 around 5:00pm

Cohabitat
2517 Thomas Ave.
Dallas, TX

If you'd like to go, please let me know, or mark it in Facebook:
http://www.facebook.com/event.php?eid=81320026376=nf

While you're considering, maybe you'll also want to come out to the
Crawfish boil and party the night before:
http://www.facebook.com/event.php?eid=61382229537

--~--~-~--~~~---~--~~
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: My Proposal [GSoC '09 Admin UI Improvements]

[Jeremy Dunck]

On Fri, Apr 24, 2009 at 6:19 PM, Zain Memon  wrote:
> Hello,
> As you might know, I'm one of the Django GSoC students this year. My mentor
> is (the) Jacob Kaplan-Moss, and he's already started corrupting my innocent
> mind.
> This summer, I'm implementing a collection of ideas with the goal to improve
> the general usability of the admin. The ideas are grouped as follows:
>
+1 in general.
...
> Reorder inlines by dragging & dropping (most likely requires a refactoring
> of the ordering APIs, according to this django-dev thread)

I'm not sure what this means.  Inline order is defined by the
underlying queryset, isn't it?  What would reordering them on the
client do in the DB?

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

Callable LazyObject?

[Jeremy Dunck]

I recently had a need for a LazyObject which was callable.  The __call__
meta method isn't forwarded to _wrapped, so it's an error to call, even if
the underlying _wrapped does support it.

In my case, was trying to do the following:

User = SimpleLazyObject(lambda: get_user_model())

User()...

I patched LazyObject to make it happy:

def _a_call_(self, *args, **kwargs):
if self._wrapped is empty:
self._setup()
return self._wrapped(*args, **kwargs)

LazyObject.__call__ = _a_call_.__get__(User)

Unfortunately, I then ran into a related problem -- by making LazyObject
callable, anyone passing a lazy user, e.g. request.user, to the ORM would
fall into the callable(value) branch:
https://github.com/django/django/blob/b77f26313cddbfde20dcf2661e9bd35458c2d1bd/django/db/models/sql/query.py#L1043

That then caused a new User to be constructed rather than using the
request.user.pk.

I see that callable criteria are deprecated there, but was wondering how
people would feel about adding a branch before that:

if ...
elif isinstance(value, LazyObject):
  pass
elif callable(value):
  ...

That would allow request.user to still be used (as it no doubt widely is)
even after LazyObject grows a callable (if its underlying object has one).

-- 
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/CAM0i3f7hshHzW9XsuRkJaT%2BaVEMetTKkzD7nUiDqMF9%2BzAR4rw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Callable LazyObject?

[Jeremy Dunck]

(It's a change in the DB code, not the template, but your point stands.)

I think I agree with you that changing LazyObject is risky when there's a
workaround and it would be difficult to address the risk of
callable(LazyObject()) becoming true.

OK, thanks for feedback.


On Thu, Mar 6, 2014 at 8:12 AM, Luke Plant <l.plant...@cantab.net> wrote:

> On 05/03/14 23:05, Jeremy Dunck wrote:
>
> > if ...
> > elif isinstance(value, LazyObject):
> >   pass
> > elif callable(value):
> >   ...
>
> My gut instinct is that if Django's template code has to be patched and
> special cased to accommodate this change, there will be lots of other
> code that needs to be patched too.
>
> LazyObject is already pretty hairy without trying to get it to support
> more things.
>
> Also, it seems that normally there should be other solutions. In many
> cases, instead of:
>
>   User = SimpleLazyObject(lambda: get_user_model())
>
> you could use:
>
>   User = lambda **kwargs: get_user_model()(**kwargs)
>
> ...assuming that the only thing you need 'User' to do is to produce User
> instances when you call it. (If you need it to be an actual class for
> some reason, then this won't work - but in most cases I'd suggest that
> the consuming code shouldn't need an actual class).
>
> Regards,
>
> Luke
>
>
> --
> "God demonstrates his love towards us in this, that while we were
> still sinners, Christ died for us." (Romans 5:8)
>
> Luke Plant || http://lukeplant.me.uk/
>
> --
> 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/53189E5F.7010306%40cantab.net
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
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/CAM0i3f4Li3Bqsz6sd1d3LURZzeOH_gQ05gK4XUdF_7GsdAL%2B8A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal for prepared statements API

[Jeremy Dunck]

On the None -> IS NULL issue, I presume there are, for any given use case,
not that many argument permutations of None and not None passed.  I suggest
that the PreparedStatement abstraction map to multiple actual prepared
statements, one for each None/not None permutation.  Then when executing,
you know the value, and you know to use the (None, not None) statement if
given (a=None, b=1) for example.

(This sort of mapping of object to different statements may be needed for
fallback on backends that don't support prepareds, as well.)

As for deferring get_prep_lookup until execution, do we lose any pruning or
other optimization opportunities for normal QuerySet usage if we go that
path?





On Tue, Mar 25, 2014 at 7:22 AM, Anssi Kääriäinen
wrote:

> On Tuesday, March 25, 2014 2:53:42 PM UTC+2, Curtis Maloney wrote:
>>
>> ps = MyModel.objects.filter(foo__lt=Param('a').prepare()
>>
>> The result is now a callable that accepts one parameter - "a".  To invoke
>> the query:
>>
>> results = ps(a=1000)
>>
>>
>> Clearly it's early days yet - I've written no code.  And akaariai has
>> pointed out already there's some corners cases which won't work well with
>> existing behaviours (e.g. foo=None being silently translated to
>> foo__isnull=True), but it's best to get this idea under wider public
>> scrutiny earlier, rather than later.
>>
>
> I like this style of prepared statements. It is explicit, and
> implementation should be achievable without too much added code complexity.
> I prefer ps.execute(a=1000) personally, but the exact syntax isn't that
> important at this stage.
>
> There will be a couple of corner cases that will be hard to solve. The
> problems are around value preparation during .filter() calls and how
> certain special values are dealt with. Quickly thinking the value
> preparation (basically get_prep_lookup() call) shouldn't be that much of a
> problem - it is currently done during .filter() calls, but it should be
> possible to defer it to execution time.
>
> The foo=None case is something that likely can't be solved. The problem
> here is that foo=None translates to WHERE foo IS NULL, while foo=1
> translates to WHERE foo = 1. These are syntactically different queries, and
> thus single prepared statement can't handle both of these. There are also
> cases where isnull=True/False require different join promotion depending if
> True or False is supplied. These again can't be handled.
>
> I am OK for just documenting these corner cases. They aren't something
> that should happen too often. The implementation for prepared statements is
> relatively straightforward (generate SQL, prepare it once, execute using
> given values), but if the corner case needs to be handled the
> implementation will be more complex, likely so much more complex that
> nobody will implement this feature.
>
> In short: +1 for implementing this with documentation of the corner cases.
>
>  - Anssi
>
> --
> 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/3123fda6-d7b3-46d3-82ec-28ed3003e837%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAM0i3f4JVV4%2B7fCV4%3Dj_Pn%2BqRAicVNp1YNBKYRFhEVtVQTsZRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-firebird backend: migrations and NULL fields

[Jeremy Dunck]

How about adding a flag to Operations? implied_null, perhaps.
On May 14, 2014 7:52 AM, "Andrew Godwin"  wrote:

> Hi,
>
> That's currently the only approach I'm afraid - there's an open issue
> (raised by Shai Berger I believe) that column_sql should be broken down
> into more component pieces so it can be more easily changed, but that's a
> difficult task to do and not something I want to go and change completely
> as we're trying to release 1.7.
>
> What we could do is change those NULL and NOT NULL strings to be defined
> on the schema editor class itself, and then you could set sql_null_suffix =
> "" or similar - do you think that would be a reasonable approach?
>
> Andrew
>
>
> On Wed, May 14, 2014 at 7:05 AM, maxi  wrote:
>
>> Hi,
>>
>> I'm trying to implement the new schema migration of django 1.7 for
>> django-firebird backend.
>> In column_sql method, when the field can be null, in firebird, is not
>> necessary add the NULL keyword. So to change this behavior I need override
>> the entire column_sql method just to change one line:
>>
>>
>> if null:
>> sql += " NULL"<-- Here
>> else:
>> sql += " NOT NULL"
>>
>> I just need:
>> if not null:
>> sql += " NOT NULL"
>>
>>
>> Is the correct approach rewrite the column_sql method? Are there other
>> approach?
>>
>> Regards.
>>
>> --
>> 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/e9f2-a5bf-4e13-b7c1-0a08abd18a4a%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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/CAFwN1upTtLEmGjz5f2vUBV6kEFDqdiyRyz4GhM3i3WbSyot0aw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAM0i3f6Jw6Bs8FEeTmU7wVwA3SQKwcruKqtTReCa_-GrxbZmww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

narrow writes (as 3rd-party library)

[Jeremy Dunck]

I'm attempting to implement narrow writes (that is, writing only fields
which have changed).

I would be able to do this as a 3rd-party Mixin library if some changes
were made to Model.save_base.

  1)  returned whether the row was created or updated, e.g. if .save_base
returned the `updated` value which it uses to send the .post_save signal.
  2) raise something finer-grained than DatabaseError when force_update is
used (so that I could then try a (wide) insert-or-update.  The new
exception could inherit from DatabaseError for backwards-compat.

Any objections to me making these changes?

-- 
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/CAM0i3f5tnHVeHeNA5cqXOzTyN-S6YbjBRtOZm7o0-noLSHiQdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Would AssertMaxQueries (similar to AssertNumQueries) be a useful addition

[Jeremy Dunck]

I use this method on my own test subclasses, and I find it useful as a
tripwire: a cause for review and consideration, more than a hard error. Did
the number of queries go up on this change? Is that reasonable or a
mistake? Have we blown the perf budget so we should refactor? Or maybe the
number should just be raised to something that seems like a reasonable next
tripwire.

These limits aren't flaky or false positives, so they seem useful supports
given a reasonable test suite otherwise.
On Aug 17, 2014 8:20 AM, "Florian Apolloner"  wrote:

> I am not so convinced, what would you put in as the upper limit? While
> preventing n+1, it still requires you to know what n in this testcase is
> and changing n can lead to funny errors. Currently we are documenting
> (hopefully) how those query counts come together, so it's clear what's
> happening when it breaks…
>
> On Sunday, August 17, 2014 4:39:17 PM UTC+2, James Bennett wrote:
>>
>> I like the idea -- if nothing else, it would provide an easy way to have
>> a test suite discover N+1 problems, especially in templates.
>>
>> Not sure about the feasibility, though; would you be willing to work up a
>> rough implementation of it?
>>
>  --
> 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/41676693-480d-4dfc-82a6-377da0f54057%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAM0i3f7nC_hVDwL2MojcQn3Qhex8TGPZnYwdYh%3DTH%2BcWN1yZ6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Two proposals for the Django Code of Conduct.

[Jeremy Dunck]

As someone affected by an issue that would fall under the proposed change
[1], I still support an explicit guideline about external behavior
influencing internal acceptance.  The safety of all members is more
important than the risk of misapplication of the rule.

[1]
http://doubleunion.tumblr.com/post/77929475144/how-not-to-support-women-in-tech
On Sep 9, 2014 11:47 AM, "Alex Gaynor"  wrote:

> When Jacob and I originally drafted the CoC, we specifically included an
> enumeration of some disallowed behaviors on the recommendation of the Ada
> Initiative -- it was their view that the list helped to minimize rules
> lawyering, whereby someone attempts to explain how they could not have
> known their behavior was disallowed.
>
> On reflection, I completely agree with their reasoning and am very glad we
> included it.
>
> Alex
>
>
> On Tue, Sep 9, 2014 at 11:43 AM, barbara.shaurette <
> barbara.shaure...@gmail.com> wrote:
>
>> As someone who has been the target of harassment at conferences (I've
>> been lucky, only minor incidents for me, although the same can't be said
>> for other of my female colleagues), I prefer explicit over implicit. If
>> someone is a harasser outside the community, I won't feel safe encountering
>> them in a conference setting either.
>>
>> That said, I trust the discretion of the core team and the DSF membership
>> and I'll be interested to see how they decide on the matter.
>>
>>  --
>> 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/9f89cb24-f572-444d-9723-386eb93e495a%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> --
> 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/CAFRnB2XfgpLy-zrb%2BSF%3D2Cz9KzErEWANYmtwmDCLn1xb8wS8yQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAM0i3f5yRYBy6qGO1R2x9QOANi_xRDCTVLBuZ7qZL2%3DwMjduPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Storage engine aliases?

[Jeremy Dunck]

Right now, I think that static/media handling is fairly confused in the
documentation, and a bit confused in the code itself.

We have a few special-cases floating around:

   default_storage (needed for legacy before storage backends)
   staticfiles_storage (needed for collectstatic/handling)
   {% static %} handles mapping relative URLs to absolute URLs, but does
not allow using a storage engine other than {% STATIC_URL %}
or staticfiles_storage.

I was surprised to find that
   django.contrib.staticfiles.templatetags
   and
   django.templatetags.static
both have implementations of {% static %} with slightly different semantics
(one based on STATIC_URL, one based on staticfiles_storage).

It seems to me that it might be useful to introduce aliases (as in CACHES
and DATABASES) in order to allow referring to storage engines in a
less-coupled way.

{% static %} could then take a storage engine alias, and the special-case
of repo-static file handling and user-uploaded file handling could mostly
go away.

MEDIA_URL/MEDIA_ROOT and STATIC_URL/STATIC_ROOT as special cases could
(after a deprecation process) go away in favor of these storage aliases.

The syntax I'll hazard as a proposal could be:

FILE_STORES = {
   'static': ,
   'dynamic': ,
   
   'alias1': 'alias2' # possibly map aliases to satisfy app-required
aliases.
}

{% file relative-url storage-alias %}

Would do people think of this idea?

-- 
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/CAM0i3f6sMwgFxAVC4P6U9Z97zAd%2B%3DmDV837KbYZmBx3ycuu%2BMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Storage engine aliases?

[Jeremy Dunck]

Aymeric,
  That's an interesting idea I hadn't considered -- perhaps storages could
also then be marked trusted and untrusted, and processing/display of those
files could take it into consideration.  I agree the security requirements
are different.

Florian,
  I agree that changing APIs would cause confusion.  It may be possible to
provide an upgrade path as we did for DATABASES and CACHES, though.

  The benefit I'm shooting for is to make media handling more modular and
clear, rather than seeming a special case.

  As for instances, yes, I was using that as a shorthand -- even so, it
could be a dict with common interface (**kwargs) handed to the storage
backend.  FileSystemStorage takes location=None, base_url=None, s3boto
takes acl=None, bucket=None, **settings.  I doubt there will be much common
interface, but to me this supports the argument that aliases would be
useful -- right now it is hard to construct a storage backend dynamically
without coding to a specific store.  connections['default'] is a powerful
abstraction.

This could be a migration path:

FILE_STORAGES = {} -> expands to
  'static': {
'class': 'django.contrib.staticfiles.storage.StaticFilesStorage',
'trusted': True, # based on Aymeric's feedback
'OPTIONS': {
   'location': settings.STATIC_ROOT,
   'base_url': settings.STATIC_URL
},
  },
  'media': {
'class': 'django.core.files.storage.FileSystemStorage',
'trusted': False,
'OPTIONS': {
  'location': settings.MEDIA_ROOT,
  'base_url': settings.MEDIA_URL
}
  }
}



On Mon, Sep 29, 2014 at 2:26 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hi Jeremy,
>
> That could be useful for any website that gets some of its assets from the
> code (JS, CSS), others from a CDN (eg. product photos), others from another
> CDN (eg. tutorial illustrations), etc. However we’d have to make sure it
> beats the common solution of having a model instance for each file and a
> method that generates the URL.
>
> Even though the documentation has improved a lot, static files still tend
> to confuse beginners. On one hand, making them less of a special case could
> help. On the other hand changing the APIs will create confusion again.
>
> Finally, static and media (user-uploaded) file have different
> requirements, especially in terms of security. I think it’s useful to keep
> the concepts separate, even if they ultimately depend on the same APIs —
> basically the Storage base class that defines the usual file APIs plus an
> URL.
>
> --
> Aymeric.
>
>
> On 29 sept. 2014, at 22:46, Jeremy Dunck <jdu...@gmail.com> wrote:
>
> Right now, I think that static/media handling is fairly confused in the
> documentation, and a bit confused in the code itself.
>
> We have a few special-cases floating around:
>
>default_storage (needed for legacy before storage backends)
>staticfiles_storage (needed for collectstatic/handling)
>{% static %} handles mapping relative URLs to absolute URLs, but does
> not allow using a storage engine other than {% STATIC_URL %}
> or staticfiles_storage.
>
> I was surprised to find that
>django.contrib.staticfiles.templatetags
>and
>django.templatetags.static
> both have implementations of {% static %} with slightly different
> semantics (one based on STATIC_URL, one based on staticfiles_storage).
>
> It seems to me that it might be useful to introduce aliases (as in CACHES
> and DATABASES) in order to allow referring to storage engines in a
> less-coupled way.
>
> {% static %} could then take a storage engine alias, and the special-case
> of repo-static file handling and user-uploaded file handling could mostly
> go away.
>
> MEDIA_URL/MEDIA_ROOT and STATIC_URL/STATIC_ROOT as special cases could
> (after a deprecation process) go away in favor of these storage aliases.
>
> The syntax I'll hazard as a proposal could be:
>
> FILE_STORES = {
>'static': ,
>'dynamic': ,
>
>'alias1': 'alias2' # possibly map aliases to satisfy app-required
> aliases.
> }
>
> {% file relative-url storage-alias %}
>
> Would do people think of this idea?
>
> --
> 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/CAM0i3f6sMwgFxAVC4P6U9Z97zAd%2B%3DmDV837KbYZmBx3ycuu%2BMg%40mail.gmail.com
> <https://gro

Re: status of 1.8 release blockers

[Jeremy Dunck]

Thank you, Tim, for shepherding this.
On Jan 3, 2015 8:09 AM, "Tim Graham"  wrote:

> Here is the fourth update with a week to go until alpha. At this time, I
> am thinking we'll have the feature freeze on Monday, January 12 as planned,
> but perhaps issue the actual alpha release a couple days later just to give
> some time for some extra polish in case any large patches are committed
> next weekend.
>
> #23861 -
>  Fields referenced in
> migrations cannot be (re)moved, even if migrations have been squashed
> 
> #23891  - Revise deprecation
> / removal timeline for IPAddressField
>  (resolved)
> Owner: Tim
> Now: I committed a patch for the second ticket and will polish the patch
> for the first issue.
> Last time: I've implemented the system check solution I proposed and am
> waiting for review and/or concerns with this approach.
>
> After completing the issue above, I'll prioritize any issues here:
>
> https://code.djangoproject.com/query?status=assigned=new=~1.8-alpha
>
> Resolved since last time:
>
> #22340 -
>  Legacy Table Creation
> Methods Not Properly Deprecated
> 
> Owner: Tim
> Now: Resolved this by removing the deprecation as discussed in the ticket.
> Last time: I took a closer look at this and don't think we need to do this
> deprecation at all as it doesn't seem to offer any benefits. See the ticket
> for details.
>
> #23745 - Migrations migrate is slow
> 
> Owner: Claude/Markus
> Now: Patch committed; thanks to Markus and Claude.
> Last time: I committed the test that Markus wrote and Claude incorporated
> a fix from Markus so the branch appears about ready for merge. Markus will
> give it another review.
>
> --
> 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/b196f095-530c-45ec-9b21-82fcd1c06ed8%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAM0i3f5KyOKN_z_OExai9ExkkThPQL3570XW0w6E6EJsO1MNQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple template engines for Django - week 13

[Jeremy Dunck]

If getting proper support for other template backends would only delay the
1.8 release timeline by a couple weeks, I think that is preferable to a
generalized 1.8 backend which only include DTL until 1.9.

What do others think?


On Sat, Jan 3, 2015 at 3:23 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> Here’s the thirteenth update (good thing I learnt all these ordinals when
> I was a kid!)
> https://myks.org/fr/multiple-template-engines-for-django/#2015-01-04
>
> At this point my main concern is the 1.8 feature freeze scheduled in one
> week.
> Dealing properly with some of the items I listed in my report for week 11
> may
> require changes falling in the "new features” bucket and therefore being
> postponed to Django 1.9. At worst, I’ll have to document that some features
> only work with the Django template language in Django 1.8. That’s sad but
> not
> worth delaying the entire project until early 2016.
>
> --
> Aymeric.
>
>
>
> > On 27 déc. 2014, at 23:59, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> >
> > Hello,
> >
> > My twelfth update is online:
> > https://myks.org/en/multiple-template-engines-for-django/#2014-12-28
> >
> > It comes with a question — should I drop `select_template` from the
> backend API? I think I should. Follow the link above for details.
> >
> > Looking forward to your feedback,
> >
> > --
> > Aymeric.
> >
> >
> >
> >> On 20 déc. 2014, at 23:57, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> >>
> >> Hello,
> >>
> >> I haven’t written to this mailing-list for three weeks because nothing
> warranted your immediate attention.
> >>
> >> Now the code is in reasonably good shape. Feel free to have a look:
> >> https://github.com/aaugustin/django/commits/multiple-template-engines
> >>
> >> I plan to merge this branch within a few days.
> >>
> >> Updates for weeks 9 to 11 are available at the usual location:
> >> https://github.com/aaugustin/django/commits/multiple-template-engines
> >>
> >> --
> >> Aymeric.
> >>
> >>
> >>
> >>> On 30 nov. 2014, at 10:37, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> >>>
> >>> Hello,
> >>>
> >>> Here’s my eight update — this is getting repetitive :-)
> >>> https://myks.org/en/multiple-template-engines-for-django/#2014-11-30
> >>>
> >>> --
> >>> Aymeric.
> >>>
> >>>
> >>>
>  On 23 nov. 2014, at 00:02, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> 
>  Hello,
> 
>  I published my seventh update:
>  https://myks.org/en/multiple-template-engines-for-django/#2014-11-23
> 
>  I have another pull request ready for review:
>  https://github.com/django/django/pull/3605
> 
>  Let me know if you have any questions!
> 
>  --
>  Aymeric.
> 
> 
> 
> > On 16 nov. 2014, at 09:19, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> >
> > Hello,
> >
> > Here’s my sixth update:
> > https://myks.org/en/multiple-template-engines-for-django/#2014-11-16
> >
> > I have a first pull request ready for review:
> > https://github.com/django/django/pull/3555
> >
> > Whenever possible, I’ll merge changes that make sense regardless of
> the Multiple Template Engines Project in small batches, in order to
> minimize the size of the final pull request.
> >
> > --
> > Aymeric.
> >
> >
> >
> >> On 9 nov. 2014, at 22:05, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> >>
> >> Hello,
> >>
> >> Here’s my fifth update:
> >>
> https://myks.org/en/multiple-template-engines-for-django/#2014-11-09
> >>
> >> The first step of my project, as outlined in my original proposal,
> is complete.
> >>
> >> --
> >> Aymeric.
> >>
> >>
> >>
> >>> On 1 nov. 2014, at 23:30, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I’m happy to annonce that the DEP is ready for public review!
> >>>
> >>> Direct link, HTML:
> >>> https://myks.org/en/multiple-template-engines-for-django/dep/
> >>>
> >>> Direct link, ReStructured Text:
> >>>
> https://raw.githubusercontent.com/aaugustin/mtefd/master/multiple-template-engines.rst
> >>>
> >>> (I’m not reproducing it here because I don’t think email is a very
> good medium for communicating 50kB of markup.)
> >>>
> >>> I’ve written a bit more about what “ready” means:
> >>>
> https://myks.org/en/multiple-template-engines-for-django/#2014-11-01
> >>>
> >>> Of course, your regularly scheduled update will also be available
> (in half an hour):
> >>>
> https://myks.org/en/multiple-template-engines-for-django/#2014-11-02
> >>>
> >>> I’m looking forward to your feedback!
> >>>
> >>> --
> >>> Aymeric.
> >>>
> >>>
> >>>
>  On 26 oct. 2014, at 22:36, Aymeric Augustin <
> 

Trac exception

[Jeremy Dunck]

I was trying to view this:
http://code.djangoproject.com/ticket/4

when I got this:
"
Oops...

Trac detected an internal error:

database is locked
Traceback (most recent call last):
  File "/usr/lib/python2.2/site-packages/trac/core.py", line 531, in cgi_start
real_cgi_start()
  File "/usr/lib/python2.2/site-packages/trac/core.py", line 513, in
real_cgi_start
env = open_environment()
  File "/usr/lib/python2.2/site-packages/trac/core.py", line 190, in
open_environment
version = env.get_version()
  File "/usr/lib/python2.2/site-packages/trac/Environment.py", line
162, in get_version
cursor.execute("SELECT value FROM system WHERE name='database_version'")
  File 
"/mnt/dar/tmp/python-sqlite-0.5.0-1.rhel3.dag-buildroot//usr/lib/python2.2/site-packages/sqlite/main.py",
line 244, in execute
OperationalError: database is locked
"

Re: Idea: "fake" model fields

[Jeremy Dunck]

On 9/16/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> tagfield = meta.FakeCharField()
> def load_tagfield(self):
> # Returns the contents of the field when it is displayed
> def save_tagfield(self, value):
...

Instead of Fake*, I suggest Deferred, or Mapped*, or Extended*.  This
idea is pretty close to the protocol of __getitem__ call when o[x] is
used.

Otherwise, neat.

> Another extremely common problem is the need to have a field
> automatically set to some value when an item is created or updated
> (most commonly a field such as pub_date or last_modified). I wonder
> if the above mechanism, or something similar, cousd be used to solve
> that one as well.

Hmm, that's muddying the waters.  I like the focus this has on mapping
in and out of the persistence layer.  What you're talking about on
this 2nd thing is eventing, right?  Maybe:

class Entry(meta.Model):
pub_date = meta.DateTimeField()

def init_pub_date(self):
   #when model is new (not from persistence)
   pass
def resync_pub_date(self):
   #when model is updated, but not necessarily pub_date.
   pass
def modify_pub_date(self):
   #when pub_date, specifically, is changed.

I'll shut up now, since I won't be supplying patches any time soon. :-/

Re: Added MS SQL Server DB support: Testers wanted!

[Jeremy Dunck]

On 10/14/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> * Run the Django unit tests with SQL Server as the backend. Just run
> tests/runtests.py ...

> The more eyes we get on this one, the sooner we can make sure it's
> solid. Thanks for any help!

I have Sql Server at work, and can test this either Sunday or Monday,
assuming all goes well setting up django on windows.

Re: Added MS SQL Server DB support: Testers wanted!

[Jeremy Dunck]

On 10/15/05, Luke Plant <[EMAIL PROTECTED]> wrote:
> > Queries with LIMIT and/or OFFSET probably won't work, because SQL
> > Server appears to use "SELECT TOP" instead of LIMIT/OFFSET. Elegant
> > solutions to this problem are welcome. :)
>
> From what I know from one of the more experienced MS SQL Server guys at
> work, there isn't an *elegant* solution to this.  The one he gave me for
> a similar problem involved creating temporary tables - I think a
> temporary table with the initial result set plus an index column, then
> SELECTing from that.  I don't know enough about the architecture of
> Django to know whether that is possible.

I can confirm that TOP is all there is.

But, something like this might work:

select *, identity(8) as "rownum" from table where rownum is between 10 and 20

I'll try to test that, too.

Ticket 683

[Jeremy Dunck]

I've added a half-patch to ticket 683.  I don't understand all the
magick going down in meta and models, but I hope the bit I did was
useful.

Re: FYI: Oracle has free edition now

[Jeremy Dunck]

On 11/1/05, Ian Holsman <[EMAIL PROTECTED]> wrote:
>
> I guess I'm a bit ho-hum about it.
>
> why?
>
> 4G limit
> single process
> no replication
> 32 bit only
> and a expensive upgrade path

I think this was a direct response to MySql 5.0 supporting views/procs etc.

And MS has had MSDE for a while, which is the free, similarly crippled
version of SQL Server.

But yeah.  Given the free features of Postgres and MySql, I'd say less
than 1% of all shops running Oracle are getting the value out of its
marginal features.

Re: Small report from Django/Rails meetup

[Jeremy Dunck]

On 11/9/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 11/9/05, hugo <[EMAIL PROTECTED]> wrote:
> > I would say: release a 0.9 version now (or in the near future) and give
> > a clear roadmap (that's what the trac feature is for ;-) ) of what will
> > go into 1.0 before release. That way people have  some "quite stable
> > but not 1.0" tarball to play with, with a defined
> > compatibility-breakage ahead, but one they are warned about. That would
> > give us a bit more time to do the 1.0 right.
>
> This sounds great to me. Thoughts, Jacob and everybody else?

This sounds something like what Robert originally suggested, with the
version number changed.  Which is to say, +1.  :)

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

[Jeremy Dunck]

On 11/14/05, Maniac <[EMAIL PROTECTED]> wrote:
> But I think this whole approach is wrong and should not be supported.
> There are certain reasons behind separating server and client part and
> wishing to break this barrier smells like a bad design to me. If Django
> will make such things easy then I can easily imagine people doing
> "select * from client where name like 'A%'" on a key press and
> complaining that this Django thing is slow...

I think some Ajax libraries may already get this right, but it seems
to me this sort of thing should be there.  What I mean is, instead of
the naive keypress event handler, you'd want to chunk it so that any
event would fire after n millisecs of inactivity, and any previously
pending request of the same class would be cancelled (since it's
wholly redundant of the latest request enqueued.

But that has nothing to do with django. :)

Re: Decoupling core Django handler from database

[Jeremy Dunck]

On 12/15/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Currently, the core handlers (modpython.py and wsgi.py in
> django/core/handlers/) wrap the main request handling in a
> try/finally, where the "finally" part closes the database connection.
> Obviously, this couples the handler to a database connection, which is
> not ideal, because people should be able to use Django without a
> database connection.
>
> However, if a person *does* use a database, we still want that
> connection.close() in a finally.
>
> Elegant solutions, anybody?

Signal?

When the request is done, raise an event.  Have db hook that event
when it's opened?  Sorry, haven't looked closely...

Re: Dojo Licensing

[Jeremy Dunck]

On 12/28/05, Tom Tobin <[EMAIL PROTECTED]> wrote:
> IANAL, but it is my understanding that one can
> only relicense code if the new license's terms are a superset of the
> old license's terms.

IANAL either, but my understanding, after reading AFL and BSD and GPL
is that AFL is basically BSD with provenance.  BSD says, "Here is some
code.  You can do what you want with it, but don't blame us if
something bad happened."  AFL continues "And here's proof that you
really can do what you want with it."  Under BSD, you have no
assurance that the code which is supposedly licensed -can- be so
licensed.  Provenance traces the contributions and assures you that
they were all contributed by the copyright holder.  There's no
assurance that BSD (or GPL) code is given by the copyright holder; viz
SCO.

Which is to say, I think AFL -is- a superset of BSD in terms of the
rights of a user of a work.

An AFL software needn't stay such; the patent protection could be
removed along with the license itself within a derivative work.  So,
as an example, I think AFL code could be tweaked to include a patented
work, and released under something other than the AFL, wherein the the
use of the software, due to the patent, would require separate
licensing.

Basically, there's no case law on this stuff, and it sucks, and I
don't see the situation getting any better.  The edifice of open
source is on shaky ground, but advances faster than the interpreting
precedence; legal singularity is here.

Re: magic-removal: "Change subclassing syntax"

[Jeremy Dunck]

On 1/25/06, Max Battcher <[EMAIL PROTECTED]> wrote:
> I've seen a home-brew Zope-based one.  It would be real quick to build
> one as a django app...  In fact its own my personal project todo list.
> How soon do you want it?  :-)

Mine, too, but you may get to it first.  As Soon As Our Copious Free
Time Makes Possible.  ;-)

Typo on magic-removal sql migration script?

[Jeremy Dunck]

I haven't been following the magic removal branch closely, but here:
http://code.djangoproject.com/wiki/RemovingTheMagic

There is a migration script for mysql.  This line looks wrong:
ALTER TABLE auth_groups_permissions RENAME TO auth_group_permissions;

Rename to the same name?
Perhaps:
ALTER TABLE auth_groups_permissions RENAME TO auth_group_permission;
?

Similarly in the postgres migration script, these look wrong:
ALTER TABLE auth_groups_permissions RENAME TO auth_group_permissions;
ALTER TABLE auth_groups_permissions_id_seq RENAME TO
auth_group_permissions_id_seq;

... I know this is trivial, but since I dunno what's changed, I didn't
want to do the wrong thing by editting the wiki incorrectly.

Re: Django sprint at PyCon

[Jeremy Dunck]

On 2/27/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
...
> On other Open Source projects I've worked on, there has been a way to
> indicate in the bug tracking system that a patch was attached to a
> report. Either by adding [patch] to the title or setting a "patch"
> keyword or something similar.

[patch] in the summary is the convention here, too.  If you see
something w/ a patch but without that notation, it'd be useful to add
it.

--~--~-~--~~~---~--~~
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: Schema evolution

[Jeremy Dunck]

On 2/28/06, Christopher Lenz <[EMAIL PROTECTED]> wrote:
> Actually, PySQLite 2.x does an implicit commit after any DDL
> statement. I don't think this is enforced at the SQLite level, but
> supposedly the PySQLite author had reasons to do this in the bindings.

Do you know what the reasons were, or where we should look for them? 
The spec sez no implicit commits:

"
Note that
if the database supports an auto-commit feature, this must
be initially off. An interface method may be provided to
turn it back on.
"

Given that there's almost no other discussion of transaction behavior,
I think this should have some weight.  Since I'm poking at SQL Server
support (which also does auto-commit), I'd like to know what the issue
was before stepping in it.

--~--~-~--~~~---~--~~
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: What if instead of calling them "projects" we called them "sites"?

[Jeremy Dunck]

On 3/2/06, Sean Perry <[EMAIL PROTECTED]> wrote:
> I am definitely -2 on this. Malcolm does a good job of starting the ball
> rolling as to why.

The range is -1..+1  ;-)

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

Buglet in tutorial 2

[Jeremy Dunck]

At:
http://www.djangoproject.com/documentation/tutorial2/

This:
"By default, Django displays the repr() of each object."

It actually uses str() now, right?

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

Re: Solving the POST-data-lost-after-redirect problem

[Jeremy Dunck]

On 6/6/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> * THROW ERROR ON POST: The CommonMiddleware, when adding a slash and
> redirecting, can check for POST data. If it finds any, it somehow logs
> the error or otherwise alerts the developer. Maybe if DEBUG=True it
> can actually display an error, with a custom-built message saying "You
> need to change so-and-so form action to so-and-so URL"? I can't think
> of any case in which a POST to a page that needs to be redirected
> would be intentional, and if we only do it for DEBUG=True I think this
> may be acceptable.

Similar to this, but:
Django can already send emails on 404.
Why not add a similar thing to RedirectFallbackMiddleware so that if
adding a slash and action = POST, send email complaining?

Between DEBUG=True and the fallback error email, I think it'd be
pretty quickly caught.

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

[Jeremy Dunck]

On 6/7/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> I already wrote a validator app that checks
> outgoing HTML for validity, using a middleware to intercept the
> response.  It also stores all details of failed pages so you can go
> back to them, which would be overkill in this case.

Hmm, this sort of thing suggests that "email when bad stuff happens"
would be a nice general feature.

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

Middleware fiddling

[Jeremy Dunck]

Is there a reason _request_middleware's are called in the BaseHandler,
while _response_middleware's are called in the subclass (i.e.
ModPythonHandler)?

Also, in BaseHandler.load_middleware, I noticed that an exception
loading any middleware will leave the middlewares not None, but also
not valid since remaining middleware's will not be loaded.   Is this a
philosophical choice (i.e. you don't want to load later middleware's
as they may depend on earlier ones or, maybe, you don't want to
repeatedly try loading a broken middleware stack) or an accident of
implementation?

If philosophical, I think leaving the middleware stack totally
unloaded is safer than leaving it partially loaded after failure of
some component.

Finally, if I understand the code correctly, it'd be useful to
document that middleware can cause the response's iterator to be
evaluated before it's actually ready to be rendered.  Which is to say,
if the iterator is intended to manage resource usage to stream large
or long responses to the client, that intent may be foiled by using
middleware like gzip.

I know these are pretty fine points.  I'm just getting more familiar
with django's internals and making notes as I go.

Cheers,
  Jeremy

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

[Jeremy Dunck]

On 6/7/06, Steven Armstrong <[EMAIL PROTECTED]> wrote:
...
> GET /some/url/?cm_data_id=78fsd8fasdf7ad8asaf7889sdf
>
> - load POST/GET data from /tmp/78fsd8fasdf7ad8asaf7889sdf, populate
> POST/GET dicts with it
> - remove cm_data_id from GET variables
> - delete /tmp/78fsd8fasdf7ad8asaf7889sdf
> - log message that data has been picked up

django.core.handlers.FileSystemHandler ;-)

--~--~-~--~~~---~--~~
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: Multiple database support (#1142) roadblock

[Jeremy Dunck]

On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'd argue that the right solution here would be to push the brains
> farther out to the edge. Have management functions call class methods
> on models to execute table creation, initial data loading, etc, rather
> than having them poll the models for information and construct and
> execute the sql themselves. Something like:

I don't deserve much of a vote, but when I peaked in manage.py, I
thought the same thing.  Wha?  All that reflection magic isn't in the
model itself?

But, yeah, it was too big a thing for me to start.  ;-)

--~--~-~--~~~---~--~~
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: "How Django processes a request", first draft

[Jeremy Dunck]

On 6/14/06, James Bennett <[EMAIL PROTECTED]> wrote:

> It's up here: 
> http://www.b-list.org/weblog/2006/06/13/how-django-processes-request

You're doing a more thorough thing, but this is a nice backgrounder to
compare/contrast:
http://simon.incutio.com/archive/2005/08/15/request

--~--~-~--~~~---~--~~
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: "How Django processes a request", first draft

[Jeremy Dunck]

On 6/14/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> On 6/14/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> > It's up here: 
> > http://www.b-list.org/weblog/2006/06/13/how-django-processes-request
>

*sigh*.  And now that I go to actually review yours, I see you linked
Simon's already.  Ignore me, it's past my bedtime.  :-/

--~--~-~--~~~---~--~~
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: RFC: Django history tracking

[Jeremy Dunck]

On 6/17/06, Vitaliy Fuks <[EMAIL PROTECTED]> wrote:
> It would be nice to record "who" made the change (optionally when there
> is a user with an id available).

+1

> I thought that storing complete row copies on both inserts and updates
> to original object isn't that bad - it certainly simplifies the
> machinery.  Because the way I was considering using this feature would
> read history tables very infrequent their size wasn't a big factor in
> my mind.

Wikipedia, probably one of the largest text diff histories, still
doesn't do compression of previous revisions.  It can wait.  ;-)

--~--~-~--~~~---~--~~
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: trac updates/changesets not being sent?

[Jeremy Dunck]

On 6/21/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On Jun 21, 2006, at 8:25 AM, Malcolm Tredinnick wrote:
> > I noticed earlier this evening that automatic documentation rebuilds
> > aren't happening, either (models-api.txt and templates.txt have both
> > been updated today).
>
> OK, got this fixed (thanks!)

Was it Unicode?  How did you find the offending bits?  Is it something
we could have helped with?  (Can we help next time?)

--~--~-~--~~~---~--~~
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: Copyright and Contributions

[Jeremy Dunck]

On 7/4/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> fingers crossed about that lame-assed ORM patent -- so I'll do what

Patents don't have much to do with copyright.  ;-)

--~--~-~--~~~---~--~~
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: Unicodification of Django

[Jeremy Dunck]

On 7/5/06, Filipe <[EMAIL PROTECTED]> wrote:
> and the first changes towards that will start appearing in python 2.5:
> http://www.python.org/dev/peps/pep-0332/

That's rejected, so not actually in 2.5, right?

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

Dave Thomas keynote at Ruby Conf

[Jeremy Dunck]

Mostly on the topic of what Rails needs to do better to get more
mainstream acceptance.
Most not very sexy.
Many, Django already does.
http://blog.scribestudio.com/articles/2006/06/30/railsconf-2006-keynote-series-dave-thomas

/me wishes he could work full time on dj 1.0.  :(

--~--~-~--~~~---~--~~
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: Modularized Django (Again)

[Jeremy Dunck]

On 7/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Just a small correction... multi-db is not a Summer of Code project,
> just a regular old nobody's-paying-me-to-do-it project. :)

Sorry about that.  The scope and timing of it made me think it was.  :-/

--~--~-~--~~~---~--~~
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: Is MS SQL Server support coming anytime soon?

[Jeremy Dunck]

On 7/25/06, Ray <[EMAIL PROTECTED]> wrote:
>
> We're using Oracle and SQL Server at work--the lack of support for
> those two is really a killer.
>
> What is involved in creating such a support for a DB--any doc/anything
> to start? Maybe I can take a look at the SQL Server side.

The short answer is that you need to add a backend for SQL Server.
ado_mssql is there and close to working, but other backends might be
useful.  You can look at the existing backends for examples of what's
needed, but mostly, it's translation from python types to DB types and
shimming from an existing DB library to DB-API (and the convenience
methods django expects over it).

This has a long history:
http://groups.google.com/group/django-developers/search?group=django-developers=%22sql+server%22+OR+mssql_g=1=Search+this+group

In a nutshell: lots of people want support for SQL Server, but there
are a couple sticking points.  The major one is that SQL Server
doesn't support LIMIT/OFFSET, which django needs (or needs a
simulation of) to support QuerySet slicing, which is used for
pagination (among other things).  The community is certainly not
against adding DB support, but the core developers are *nixen and so
can't help much on this.  Any testing and maintenance will have to be
contributed.

Longer answer:
The existing nearly-working ado_mssql backend (look in
django.db.backends.ado_mssql) is also Windows-only since it relies on
ADO.

There are loads of tickets related to getting this working, some of
which are nearly complete.  Unfortunately, I've lost track of which is
which.  Getting a single, consolidated ticket and closing all the
others would probably really help get people focused.  ;-)
http://code.djangoproject.com/search?q=%22sql+server%22=on
http://code.djangoproject.com/search?q=%22ado_mssql%22=on

There's a cross-platform SQL Server library called pymssql which uses
FreeTDS--- getting support using that would probably be preferable.

There are some misgivings about using pymssql.  One is that it depends
on a deprecated library, "MS SQL 2000 DB-Library for C".  To me, that
doesn't matter, since it'll still work with SQL Server 2000 and 2005,
and since a new wrapper for FreeTDS will be available by 2009.  ;-)

But also, using ODBC might work, see
http://groups.google.com/group/django-developers/browse_thread/thread/c2d33cb6a9987eb6/f4907833618b80c5?lnk=gst=%22sql+server%22+OR+mssql=2#f4907833618b80c5
mxODBC apparently can interface with a large variety of ODBC drivers,
and there is a *nix ODBC driver for SQL Server here:
http://www.datadirect.com/products/odbc/index.ssp

But don't expect stellar performance from
django->mxodbc->datadirect->sql server.  And I personally would rather
eat dirt than pay for a data access library.  :)  That sort of thing
is great to have when you realize valuable data is on the verge of
being lost forever, but you can save it by shelling out some cash for
migration to a more accessible system.  Deploying it by choice as the
backend accessor, eh, not so much.

Another (misgiving about pymssql) is that, AFAICS, pymssql pulls back
the entire resultset upon query execution, rather than fetching cursor
pages.  I think this is to satisfy the DB-API's cursor.rowcount
requirement, which SQL Server can't supply using a forward-only (i.e.
fast) cursor.  ado_mssql doesn't do that, but instead doesn't comply
with DB-API because it always returns a rowcount of -1 until you've
fetched the whole set locally, which is less than useful.  It comes
down to a limitation in SQL Server.  The only way to comply with
DB-API without pre-fetching the entire resultset (which I think is a
horrible idea) is to pre-select the count.  Which is also a horrible
idea since on edge cases the count could differ from the actual result
due to interim updates or dirty reads.
DB API 2.0 : http://www.python.org/dev/peps/pep-0249/

Another person is apparently currently looking at adding support for SQL Server:
http://groups.google.com/group/django-developers/browse_thread/thread/6fa803c0fdcb82f3/76cbb95ec2fd6dfd?lnk=gst=%22sql+server%22+OR+mssql=4#76cbb95ec2fd6dfd

As noted in that thread, django.db.models.query is being refactored
currently, so you'll want to discuss with Adrian if changes in there
are needed (and I think they probably are,

I don't know what's involved with Oracle, since I haven't looked into
it as much.  I want Oracle support as well, but SQL Server matters
more to me.  ;-)

...I wish I had time to put this issue to bed.  I've become the
curator of the issue history since my failed attempt to get this
working over PyCon (March 2006, should the date become of historical
interest).At least I now have a message I can point future
inquiries at.   :)

  Lastly, this discussion probably should live on django-developers.

  Cheers,
  -Jeremy

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to 

Re: Consider releasing a .95 beta

[Jeremy Dunck]

On 7/27/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
> People run svn update at
> different times and all that jazz.  I know we've been burned once or
> twice by people running different versions of django.

Two-phase email?  "I'd like to svn up, report back when ready."

Or, if too large a team, cron'd switchtower/capistrano task?

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

[Jeremy Dunck]

On 7/27/06, Matt the Destroyer <[EMAIL PROTECTED]> wrote:
> Does Django improve if everyone's out for lunch?

I think that depends on whether we're all friends here.  I certainly
think about Django over lunch often.

--~--~-~--~~~---~--~~
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: Default escaping -- again!

[Jeremy Dunck]

On 7/27/06, Deryck Hodge <[EMAIL PROTECTED]> wrote:
>
> On 7/27/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> > Make a setting to turn define the default, and if the setting's not
> > there, auto-escape.
> > Anyone that doesn't want it can just turn it off by defining the setting.
> >
> > AUTO_ESCAPE_TEXT = _True_|False
>
> This is the exact scenario that should be avoided most, which came up
> last time this was discussed.  What if I have all the apps on my site
> without auto-escaping by default, but another person's app, which I
> want to incorporate into my site, expects auto-escaping?

So, I'll hold my water until we hear back from Jacob et al.

--~--~-~--~~~---~--~~
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: If there was massive security hole found in Django, are there plans in place to deal with it?

[Jeremy Dunck]

On 8/9/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> I'm not completely sure I agree with the way the Ruby team are handling
> this release, but since I don't know the details yet, I can't really
> work out what is happening; they may have very good justification for
> the way they are doing it, or they may just be slightly shell-shocked.

Dave Thomas, who is heavily involved with Ruby yet not Rails-core, and
who I think has very good judgement, thinks the issue is severe enough
that they're doing the right thing to let people hear and upgrade
before full disclosure.

> something that is essentially pre-release for mission-critical work, you
> are implicitly taking on the responsibility of watching carefully for
> things like this.

True, but Rails had lots of buzz and has -lots- of prod systems.  Of
the 2 people I talked to with prod rails systems, neither had heard of
this 3 hours after the posting.  I only knew because of luck on
prog.reddit.

Security is freaking hard.

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

Admin lockout

[Jeremy Dunck]

In the admin, it's possible to disable all superuser accounts.  It'd
be good to not allow the last one, or to warn against it.

--~--~-~--~~~---~--~~
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: Admin lockout

[Jeremy Dunck]

On 8/10/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I'm not so sure about this... It seems like protecting people from
> themselves. Presumably the "real" superuser has access to Python code
> and the database, so that person can make the change in the database,
> or via the Python API, if worse comes to worse.

Yeah, that's what I did.  I just didn't know that superuser=coder.

Thanks,
  Jeremy

--~--~-~--~~~---~--~~
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: A final post-0.91 release?

[Jeremy Dunck]

On 8/11/06, Deryck Hodge <[EMAIL PROTECTED]> wrote:
> I know at NDN we're going to be pre-mr for the foreseeable future (and
> probably all of Scripps, too).  Even if not an actual release, just
> compiling a set of patches known to be useful for those on pre-mr
> releases would be nice.

+1 from Pegasus News-land.

--~--~-~--~~~---~--~~
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: Security questions

[Jeremy Dunck]

On 8/13/06, Jakub Labath <[EMAIL PROTECTED]> wrote:
> 2. Due to time/money reasons I am running a relatively old version of
> django. I realise that by doing that I'm left on my own. However It
> would be nice to be able to go to Trac or somewhere and see all
> security related bugs/fixes so that I can back port them to my
> version.

How old?
It looks there will be some work backporting bugfixes to 0.91.
http://groups.google.com/group/django-developers/browse_thread/thread/587004d127dd9444/a748f75990565a6e#a748f75990565a6e

(I have a site running on an even older codebase, ouch.)

> Right now all I found is "Active tickets by keywords" report. Are

What version of trac is the site running?  I've previously thought
about writing some additional reports, but it appears Trac is changing
to have an actual reporting engine.  ;)
"
Note: The report module is being phased out in its current form
because it seriously limits the ability of the Trac team to make
adjustments to the underlying database schema. We believe that the
query module is a good replacement 
"
http://trac.edgewall.org/wiki/TracReports

--~--~-~--~~~---~--~~
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: django unicode-conversion, beginning

[Jeremy Dunck]

On 8/16/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> Now. Most (all?) browser UAs sniff the content to second guess the media
> type. They don't much pay attention to Content-Type (I think maybe IE
> ignores it altogether). The problem for this example is they might be
> doing something similar for character encodings declared on the form
> page's GET request. Browsers do this because so much served content is
> mislabelled (eg feeds served as text/html and video as text/plain).

IE doesn't totally ignore it.  I just does some horrible, wrong things
while considering it.
http://blogs.msdn.com/ie/archive/2005/02/01/364581.aspx
http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp

Ian Hickson says contenttype is dead:
http://ln.hixie.ch/?start=1144794177=1
http://ln.hixie.ch/?start=1154950069=1

Happily, Mark Pilgrim did a lot of the hard work by converting
Mozilla's charset detection routines to Python in support of his feed
parser.
http://chardet.feedparser.org/docs/how-it-works.html

--~--~-~--~~~---~--~~
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: django unicode-conversion, beginning

[Jeremy Dunck]

On 8/9/06, gabor <[EMAIL PROTECTED]> wrote:
> hmmm.. are you sure that the situation with unicode-aware editors is so bad?
>
> could you name some non-unicode-aware editors?
> for me it seems that from notepad through vim to eclipse everything does
> unicode fine...

On Windows, I used UltraEdit, which is a very popular editor.  $25ish
with very nice features.
It claims to support unicode, but I've tested with it and it horribly
mangles anything but UTF-8.  Worse, you can open a UTF-8 file as
though it were ASCII, then save as unicode, causing double-encoding.

I hearby degree that all strings in computing should have a charset
associated with them.

...

Damn, it didn't work.

--~--~-~--~~~---~--~~
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: django unicode-conversion, beginning

[Jeremy Dunck]

On 8/16/06, gabor <[EMAIL PROTECTED]> wrote:
> 3. will assume the database is in DEFAULT_CHARSET
> - maybe can we somehow ask the db for it's charset?

I think you really have to allow for different charset in the DB--
legacy integration, remember.

--~--~-~--~~~---~--~~
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: JavaScript and Changeset 3541

[Jeremy Dunck]

On 8/18/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Sure, I'd be happy to explain -- my (very strong) preference is to
> bundle *no* JavaScript toolkit. That's partially because we shouldn't
> limit which toolkit developers use, and partially because it's
> unnecessary bloat within the Django distribution.

What about something like django.contrib.client?

This leads me to wonder whether there should be release flavors (a la
slackware vs. ubuntu) down the road.

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

BigIntegerField

[Jeremy Dunck]

I'd like an integer field larger than postgresql's integer (2^31).

Any interest in a patch for BigIntegerField?

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

Rails has a Naked Objects tool (aka automagic gui)

[Jeremy Dunck]

I hadn't seen this mentioned on the lists.

http://streamlined.relevancellc.com/articles/2006/08/02/screencast-available

--~--~-~--~~~---~--~~
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: Automatic-manipulator, very slow..... design-decision/bug/misunderstanding?

[Jeremy Dunck]

On 8/31/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> I mean when you're creating a manipulator you can list fields that you
> don't want it to touch:
>
>  manipulator = Owner.AddManipulator(follow={'thing': False})

Thanks; I don't see that documented.  Probably because manipulators
will go away...

--~--~-~--~~~---~--~~
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: XSS comments from PHP Creator

[Jeremy Dunck]

On 8/22/06, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
> But if you keep poking holes in all the wrong places, then it is not
> the frameworks fault.
>
> Autoescaping might be a nice DRY feature, but I don't think it has
> anything to do with being secure by default.

Usable security is about making it easier to do the things that make
or keep you secure and making it less easy to do things that are
dangerous or insecure.

Everybody using dj templates is putting context into them all the
time; most of the time it's fine.  You're trained into doing something
by rote and sometimes it's wrong.

Interaction with applications (even text editors and codelibs) wears
grooves in the judgement of people.  Escape by default is the Right
way.  I'd much rather see a double-escaped whoopsie than have my
cookies stolen.

--~--~-~--~~~---~--~~
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: Re: A final post-0.91 release?

[Jeremy Dunck]

On 8/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> OK, I've set up a 0.91-bugfixes branch and given you commit access. Have at 
> it!
>

It looks like neither branch is particularly lively just now.  I'm
trying to decide whether to catch up to 0.90 or 0.91 from r1338.  Of
course 0.90 is easier to get to, but if more developers are coding on
0.91, then maybe I'll try to catch that.

Thoughts?

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

Re: Re: Re: A final post-0.91 release?

[Jeremy Dunck]

On 9/19/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 9/19/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> > Of
> > course 0.90 is easier to get to, but if more developers are coding on
> > 0.91, then maybe I'll try to catch that.
>
> Well, if you can point me at bugs that need to be fixed in either one
> I'll happily get on it :)
>

We're now on 0.91 (but not -bugfixes yet).
We just ran into http://code.djangoproject.com/ticket/2745 , which has
not been applied to 0.91-bugfixes yet.

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

Re: Contrib context processor?

[Jeremy Dunck]

On 10/13/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 10/13/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> > I'm adding it locally, but was wondering if you'd like a patch for one
> > either to core or contrib?
>
> It came up in ticket 2532, and Adrian vetoed it on the grounds that
> adding context processors for some settings could be a slippery slope
> toward having a context processor for every setting.

Eek.  Sorry.  :-/

--~--~-~--~~~---~--~~
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: Q and the | operator (related to ticket #2253?)

[Jeremy Dunck]

On 10/13/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Ticket #2253 is in the process of being fixed as part of a larger
> change, so micro tweaks as you are suggesting, whilst they may or may
> not fix #2253 are going to be swallowed up in the changes (it's one of
> the test cases for the new changes, so it will be fixed).
>

Is there a page or ticket discussing the larger change?

I've several times lately wished for a couple edge-case Q objects.

--~--~-~--~~~---~--~~
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: Data for globalization

[Jeremy Dunck]

On 10/15/06, GinTon <[EMAIL PROTECTED]> wrote:
> And here you have the files for add/integrate them to any Django
> project:
> http://satchmo.python-hosting.com/file/trunk/satchmo/G11n/
> http://satchmo.python-hosting.com/file/trunk/satchmo/load_G11n.py

It may be too much work, or you may not be interested, but consider
adding these to your language table:

MARC
 http://www.loc.gov/marc/languages/langascii.html

 IANA
 http://www.iana.org/assignments/language-subtag-registry

MARC is a standard for bibliographic records, and that IANA registry
is the internet code.  (I think 630-2 and 3066 may have a strong
overlap.

--~--~-~--~~~---~--~~
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: handlers.modpython.is_secure -- why not use self._req.is_https() ?

[Jeremy Dunck]

On 10/24/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> In other words, I hope I haven't talked you into breaking trunk.  :-/
>

Relevant (or so I thought) doc:
http://www.modpython.org/live/current/doc-html/pyapi-mprequest-meth.html

--~--~-~--~~~---~--~~
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: What's going on with all these branches?

[Jeremy Dunck]

On 10/31/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> This comes up every few weeks.
>

I've wikified this response here:
http://code.djangoproject.com/wiki/ActiveBranches

I linked to any branch detail pages I could find, relevant groups
discussions, and added a suggestion to test one of them in
LittleEasyImprovements.

It'd be nice if branch contribs (or gnomes) could keep the
ActiveBranches page up to date.

I tweaked contributing.txt, in case the committers want to link from
there to ActiveBranches.
Patch attached.


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


contrib-active-branches.patch
Description: Binary data

Re: State of MSSQL support

[Jeremy Dunck]

On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Thanks.  Any idea as to why adodb was used instead of native
> interaction?
>

By that, you mean FreeTDS via pymssql?  It was GPL at the time, and
it's now LGPL.  I think that's the only reason, though.

--~--~-~--~~~---~--~~
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: Ticket spam

[Jeremy Dunck]

On 11/2/06, Christopher Lenz <[EMAIL PROTECTED]> wrote:
...
> Continuing the monologue... See:
>
>

I, for one, am happy to see your efforts.

--~--~-~--~~~---~--~~
 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: Branch Merges?

[Jeremy Dunck]

On 11/6/06, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> search-api has a wiki page here:
> http://code.djangoproject.com/wiki/TextIndexingAbstractionLayer
>
> There is currently one supported indexer (Lucene) and a couple
> experimental (Xapian).  It needs polish. I blogged about the status a
> while ago here:
> http://blog.case.edu/bmb12/2006/08/merquery_summer_of_code_results

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

Session renewal: want a patch?

[Jeremy Dunck]

Currently, sessions are renewed only if 1) they're modified or 2) every request.

There's a middle ground that's useful: renew the session and cookie if
it's within X days of the session's current expiration.  This keeps
cookies for unmodified sessions from expiring while not sending out a
cookie on every request.

Would you like a patch for that?  Something like:

if request.session.session_key:
existing_expires =
sessions.get_values(fields=['expire_date'], limit=1,
session_key__exact=request.session.session_key)[0]['expire_date']
else:
existing_expires = (datetime.datetime.now() +
   datetime.timedelta(days=1))
#fake date way in future so we never write out a cookie
# for an unmodified session

renewal_date = (datetime.datetime.now() +
datetime.timedelta(days=settings.SESSION_RENEWAL_DAYS))

if (modified or
SESSION_SAVE_EVERY_REQUEST or
existing_expires < renewal_age):

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

0.91-bugfixes: response middleware applied even though request middleware returned a response

[Jeremy Dunck]

I just ran into a problem caused by response middleware getting called
even though request middleware returned a response.  The docs, even in
0.91, claim that all response processing stops if request middleware
returns a response, but this was not the case, even on trunk, until
[2358], while 0.91 was [1908].

This was (possibly inadvertently) fixed in that changeset by returning
from get_response, which bypasses the later code that used to be in
ModPythonHandler.__call__.

This is the third or so request to have a bug applied to
0.91-bugfixes.  I'm not at all upset, but the prior requests haven't
been answered.  Would it be possible for me to gain committer access
on that branch?  I'm fixing bugs over there anyway.  ;-)

Cheers,
  Jeremy

--~--~-~--~~~---~--~~
 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: 0.91-bugfixes: response middleware applied even though request middleware returned a response

[Jeremy Dunck]

On 11/10/06, James Bennett <[EMAIL PROTECTED]> wrote:
> Can you point me to the other requests?
>

Apparently, I exaggerated.  I could only find one other request, at
the end of this thread:

http://groups.google.com/group/django-developers/browse_thread/thread/587004d127dd9444/5ffe71f43a099d22?lnk=gst=A+final+post-0.91+release=1#5ffe71f43a099d22

I'm working on a list of other fixes I've made or have applied to our
flavor of 0.91.

--~--~-~--~~~---~--~~
 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: Branch Merges?

[Jeremy Dunck]

On 11/15/06, Aidas Bendoraitis <[EMAIL PROTECTED]> wrote:
>
> I am just curious, what the status of per-object-permissions branch
> is. Today I noticed that the most recent revision number of that
> branch matches the revision number of trunk. Does that mean, that the
> per-object-permissions branch is up to date with the trunk? What is
> still missing in that branch so that they could be merged.

Subversion revision numbers apply to the whole repository.  Look at
the log for /branches/per-object... for the last "merged to [x]"
message.

--~--~-~--~~~---~--~~
 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 faster SelectBox.js

[Jeremy Dunck]

On 12/6/06, Graham King <[EMAIL PROTECTED]> wrote:
> PS:
> If you have lots of elements in your select box, and your object has a
> FileField (meaning multipart encoding on your form), you might run into
> an intermittent bug Saving, whereby in http.__init__ on this line:
>
> name_dict = parse_header(submessage['Content-Disposition'])[1]
>
> parse_header gets give None.
> This is, believe it or not, a Python email package bug:
> > http://sourceforge.net/tracker/index.php?func=detail=170_id=5470=305470


Christ, I've been trying half-heartedly to reproduce that for ages.

I just pinged the python bug to get it fixed.

I don't see a way to work around this without patching
email.message_from_string.

All, here's a traceback for the problem, for future searchers:

 File "/pegasus/code/current/django/utils/httpwrappers.py", line 46,
in parse_file_upload
   name_dict = parse_header(submessage['Content-Disposition'])[1]

 File "/usr/lib/python2.4/cgi.py", line 331, in parse_header
   plist = map(lambda x: x.strip(), line.split(';'))

AttributeError: 'NoneType' object has no attribute 'split'

--~--~-~--~~~---~--~~
 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 faster SelectBox.js

[Jeremy Dunck]

On 12/6/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > nice gui widget, runs too slowly, and the browser will complain.
>
> if I had to use a multi-selection box with thousands of entries in it,
> I'd probably run around and complain too.
>

The filter_interface makes it much less painful.  :)

I'm wavering about doing an auto-complete, but I think those make the
assumption that a user will know what to start typing.

--~--~-~--~~~---~--~~
 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: Thinking out loud: move auth.Messages into the sessions app?

[Jeremy Dunck]

On 12/11/06, Zak Johnson <[EMAIL PROTECTED]> wrote:
>
> James Bennett wrote:
> > Which leads me to wonder whether it wouldn't be better to just do that
> > in Django itself, and move the Message model into
> > django.contrib.sessions.
>
> +1.  Associating messages with sessions is much more intuitive to me;
> when first switching to Django, I was surprised they didn't already work
> that way.

Doesn't this create a small chance that messages intended for one user
would be given to another user this way?

Acceptable risk, perhaps, but just noting it.

--~--~-~--~~~---~--~~
 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: DjangoPoweredSites wiki article vandalised, please revert

[Jeremy Dunck]

On 12/11/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> Fixed; thanks for pointing it out.
>

It seems to be missing now...
http://code.djangoproject.com/wiki/DjangoPoweredSites

--~--~-~--~~~---~--~~
 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: Re: Thinking out loud: move auth.Messages into the sessions app?

[Jeremy Dunck]

On 12/11/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 12/11/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> > Doesn't this create a small chance that messages intended for one user
> > would be given to another user this way?
>
> Not that I can tell; two users should never be sharing an instance of Session.

Hmm, in our dj codebase, logging out doesn't expire the session
cookie.  I'll have a look at trunk.  I agree it's a useful property.
:)

--~--~-~--~~~---~--~~
 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 faster SelectBox.js

[Jeremy Dunck]

On 12/12/06, graham_king <[EMAIL PROTECTED]> wrote:
>
>  Has anyone else had a chance to test this new SelectBox.js ?

I've just started using it.  We have about 15 people using admin most
of the day.

> I would
> really appreciate if someone could drop this js into their app and take
> a look - I guarantee you faster select boxes and faster page load times
> on all your admin interface that uses the filter interface

>  If just one person could give it a test, I think there's a good case
> for integrating it into the trunk.

There were a few things you changed that were actually
de-optimizations in favor of readability.  None of them matter
anywhere near the O(n^2) you got rid of, but they do increase the O(n)
constant.  :)

Specifically, things like this:
for (var i = 0, j = SelectBox.cache[id].length; i < j; i++) {
are now like this:
for( var i=0; i

Re: Thinking out loud: move auth.Messages into the sessions app?

[Jeremy Dunck]

On 12/12/06, Rob Hudson <[EMAIL PROTECTED]> wrote:
> In one of those articles, he describes the "impersonation" scenario,
> which is what I wonder if Jeremy is referring to:

No, I was referring to the situation James outlined earlier.

But I agree session hijacking is a concern, though totally unrelated
to the discussion of whether to move messages to sessions.  :)

I have also thought about creating session IDs w/ IP salt, but I'm not
sure that's either useful or dependable, and hadn't come up with a
better idea.   I like to pretend that MITM session theft is something
that doesn't happen in the real world...

--~--~-~--~~~---~--~~
 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: Session security (was Re: Thinking out loud)

[Jeremy Dunck]

On 12/12/06, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
> Sessions are based on data passed from the client to the server.
> Because this data can easily be forged, session impersonation is
> possible.  That's where picking hard-to-guess identifiers comes in.
> If you have a secure random session ID, you can effectively rule-out
> guessing, but you can't rule-out malicious behavior (such as browser
> exploits).
>

With sparse session keys, the only reasonable attack I can see is MITM
or replay.  And no fingerprinting based on the request will help that,
since all the headers are in the clear.

--~--~-~--~~~---~--~~
 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: Regarding the copy of forms -> oldforms

[Jeremy Dunck]

On 12/21/06, Rob Hudson <[EMAIL PROTECTED]> wrote:


Would Michael Radziej's suggestion work better for those who develop
against trunk but whose servers are running stable releases (ie: 0.95)?
 That's my case and I just ran up against this issue.


If you're doing that in the expectation that running "stable" is less
risky, I imagine the discrepancy between dev and prod is more risky.
Or perhaps you have a test server which is running the same codebase
as prod?

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

Schema evo (actual movement!)

[Jeremy Dunck]

For whatever reason, there's been a lot of rustling about schema evo
on the dju list.

I thought I'd draw attention to this thread:
http://groups-beta.google.com/group/django-users/browse_thread/thread/bd1417a08e37774a/e157ea7b4a37b556

On dec 16, Victor Ng reported good progress towards a workable schema
evo and asked for mentoring on his work.

On dec 22, having received no reply from the SoC branch folks, he
asked for commit access on the branch or a new branch.

I'm not trying to force the issue, just trying to draw attention to
someone actually writing code and asking for a bit of help finishing
it up.

Happy New Year.  :)

--~--~-~--~~~---~--~~
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: Has anyone looked at ticket #1476?

[Jeremy Dunck]

On 12/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


I am new to Django and web development for that matter but I saw ticket
#1476 posted about related objects being displayed as lists with a link
to allow the user to edit.


Yeah, that looks useful, but Joseph never submitted a patch that
implements the feature.  Perhaps he hit a snag, but it's hard to tell.


 I want the list to look very similar to what
the admin builds for their lists with a button to allow you to add a
new one.


I assume you've already looked at making phone and address edit_inline
on Person?


I have read as much as I can to find a solution but I just can't seem
to grasp the best way to do this?  Do I need to build my own custom
view?  If so, how do you plug in a custom view to be used in the place
if the view that is generated?


Chapter 18 (not yet released) of the Django book should cover this:
http://www.djangobook.com/en/beta/

--~--~-~--~~~---~--~~
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: Signed Cookies (ticket #3285)

[Jeremy Dunck]

On 1/12/07, Gulopine <[EMAIL PROTECTED]> wrote:
...
> I should note, however, that security extends only so far as preventing
> a user from tampering with the cookie. If the cookie itself is
> compromised and removed from the computer by an attacker, it would
> presumably still be considered valid if it accompanied a request from
> the attacker's computer.

That's true with existing session-key cookies, of course.

> ...If the cookie is stolen, that user's secret key
> could be reset by an admin (after noticing suspicious activity), or
> directly by the user (after validation of the user's account password).
>
> This would hardly be a real solution, though, since it relies on
> someone noticing the cookie has been stolen and taken action
> appropriately. It would also require a hit to the database each time as
> well, regardless of whether the password is stored in the cookie.

Well, right now, stolen session keys can be made invalid simply by
removing them from the session table.  Any signed-cookie auth should
probably include something like this in order to have the same ability
to revoke.

--~--~-~--~~~---~--~~
 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: Using Capistrano to Deploy/Maintain Django Applications

[Jeremy Dunck]

On 1/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


Has anyone used Capistrano with Django? I have been looking for
documentation, and the Cap manual uses RoR for its examples - it's not
very approachable for someone doing application deployment outside of
that framework.


Maybe post of django-users?

I looked at using Capistrano (nee` Switchtower) when starting work at
Pegasus, but at the time, we only had 1 db and 1 web server, so after
fiddling with it for about an hour I decided to put away my toys.  :)

I guess that's to say I got about as far as you...

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