ced it works well for any project, if used responsibly.
--
Dennis K.
They've gone to plaid!
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubs
hink we will probably be able to get more
> aggressive about dropping Python versions, but let's cross that bridge
> when we get to it.
As one of those RHEL users in larger environments, I really appreciate
this policy and the fact that you have so far followed it and are
planning to contin
el?
- Were OS/database level caches equally hot or cold?
--
Dennis K.
They've gone to plaid!
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsub
On wo, 2010-07-28 at 14:20 -0500, Jacob Kaplan-Moss wrote:
> On Wed, Jul 28, 2010 at 2:08 PM, Dennis Kaarsemaker
> wrote:
> > As implemented in my github branch it is called once (well, twice, pre
> > and post) per update() statement, not once per object.
>
> Okay
On wo, 2010-07-28 at 13:43 -0500, Jacob Kaplan-Moss wrote:
> On Wed, Jul 28, 2010 at 12:53 PM, Dennis Kaarsemaker
> wrote:
> > This would add boilerplate to each class and makes it nontrivial to do
> > update() tracking for third party applications. I don't see why pre/post
On wo, 2010-07-28 at 12:02 -0500, Jacob Kaplan-Moss wrote:
> Hi Dennis --
>
> I'm not totally thrilled with this proposal, though perhaps there's
> some points I just don't get. As it is, though, I'm -0 on the idea.
> update() is supposed to be an optimization t
Is nobody interested?
I'm using this in production for auditing purposes and works just fine.
If only it were built in, then I wouldn't have to monkeypatch :)
I've rebased it to trunk again and it still works.
On wo, 2010-06-16 at 14:38 +0200, Dennis Kaarsemaker wrote
hanks in advance for considering and commenting,
[1] http://code.djangoproject.com/ticket/13021
[2] http://github.com/seveas/django/tree/seveas/ticket13021
--
Dennis K.
The universe tends towards maximum irony. Don't push it.
--
You received this message because you are subscribed to the Google G
I
believe that it will happen.
--
Dennis K.
They've gone to plaid!
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this grou
used it though, I'm not suggesting it as an alternative to trac)
--
Dennis K.
They've gone to plaid!
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
n django in a
similar way: a github repo with per-ticket branches that are trunk-ready
and regularly updated (rebased) against trunk until they are applied.
So far I've only done so for a pony of mine as a test, but as soon as
the ash cloud clears, I will look at existing tickets. Would this
7;re not going to cut a 1.1.X
> release until 1.2-final
Agreed again.
> * Direct feedback from the #django and django-users trenches might
> have avoided this problem
> * We'll try to do better next time.
I will try to do better as well, bringing up often-reported problems on
the
tead of as a release on its own. I've yet
again seen a case of python 2.6.5 breaking django tests, so I would
welcome a new release of 1.1.x a bit sooner than 1.2, if only from a
#django support perspective.
--
Dennis K.
They've gone to plaid!
--
You received this message because you ar
RedHat, and RHEL5 ships with Python 2.3.
Rhel 5 ships with 2.4, rhel 4 shipped with 2.3. I still have to use
django on the latter, so the support for 2.3 being dropped is an issue
for me. Then again, rhel 4 is positively ancient and I really should
move on :-)
--
Dennis K.
They've gone t
expect to see this patch in a 1.1.x release? The problem is
coming up in #django suspiciously often (3 times in the last week so
far).
--
Dennis K.
They've gone to plaid!
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post
er python nor django at the moment support it and that django
will need to implement its own cookie handling if it wants to continue
supporting python versions as old as 2.4.
There are patches attached to the issue, but none of those have been
applied to django yet.
--
Dennis K.
The universe tend
On ma, 2010-03-08 at 08:09 +0800, Russell Keith-Magee wrote:
> On Mon, Mar 8, 2010 at 7:56 AM, Dennis Kaarsemaker
> wrote:
> > I have now added tests and documentation. Comments are still welcome, I
> > have not received any feedback yet :(
>
> Please don't take it
I have now added tests and documentation. Comments are still welcome, I
have not received any feedback yet :(
On wo, 2010-03-03 at 19:00 +0100, Dennis Kaarsemaker wrote:
> I know that queryset.update does not call .save() for each instance and
> I know why. I even agree with it :)
>
roach suitable for inclusion in django? If so, I
will complete the patch, add tests and documentation and will submit it
for inclusion at the appropriate time.
Thanks in advance for considering and commenting,
--
Dennis K.
The universe tends towards maximum irony. Don't push it.
--
You received th
e me happy? Thanks!
--
Dennis K.
The universe tends towards maximum irony. Don't push 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-develop...@googlegroups.com.
To unsubscribe fr
> Signed cookies are useful
> for all sorts of things - most importantly, they can be used in place
> of sessions in many places, which improves performance (and overall
> scalability) by removing the need to access a persistent session
> backend on every hit. Set the user's username in a signed c
(~(Q(x=None)|Q(y=None)|Q(z=none))
--
Dennis K.
The universe tends towards maximum irony. Don't push it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this g
Alex Gaynor wrote:
> Are you using the auth middleware? If so it will be hitting the
> session each query, even if your stuff doesn'tm
>
> Alex
>
> On 3/8/09, Dennis wrote:
>
>
>
>
>
>
>
> > Memcached-backed sessions seemed to be created, even when
Memcached-backed sessions seemed to be created, even when the session
is not written to.
This is what I'm finding when I look at my memcache after hitting a
page that does not use sessions.
Thus, if an app uses sessions (but not much), memcache will fill up
with empty sessions.
(the same thing mi
Hi there,
if this will be deactivated in 1.0, how do I have to replace this? I
couldn't find an easy way like this in the docs yet.
Regards,
Dennis
On 23 Aug., 18:43, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sat, 2008-08-23 at 16:02 +0200, Alex Rades wrote:
> > Hi
Secret Dating Tips !!!
http://www.webdatingtips.co.cc/
--~--~-~--~~~---~--~~
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
FREE International Calls sign up free!!!
Lowest rates, highest quality calls to and from any number in the world
http://www.attphone.co.cc/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
27 matches
Mail list logo
