Re: RFC: "UPSERT" in PostgreSQL

[shmengie]

To upsert or to merge.  Sparked a lot more emotion than I would have 
anticipated.

Both ideas, have similiar functionality, they solve marginally different 
problems.

Both have the objective of reducing client server traffic involved with pk. 

Merge -- bulk loading foreign data -no guaranty

upsert -- insert or update row w/confidence.

Peter, please add the upsert as intended.  After you finishing this 
objective, if you would kindly consider working on merge, you'd please 
everyone ;)

Upsert adds a feature, I think more of us can identify and would enable 
interactive performance gains.

Merge would save some fewer ppl a lot of development effort, for when its 
time to perform merge, more development effort is required.  I've worked 
around (the lack of) both features, so I understand the passions that 
arise.  The features are similar, I would request YOUR additional effort to 
add Merge after Upsert.

Kudos either way!

-Joe

-- 
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/6276a9f4-8271-4164-af42-dc52f3c74851%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please don't kill the ecosystem

[shmengie]

Pkl, 

You shouldn't have to upgrade all your old sites to the latest version of 
Django, unless you want maintain current methods. 

This is why we like virtual environments, much.

The core team has made a nice set of security releases available via pip.  
Django 1.4.14, Django 1.5.9, Django 1.6.6, and Django 1.7

# See package version in your environment
$\> pip freeze

# This command should get fetch security updates w/out breaking eco-system.
$\> pip install Django --upgrade


# Worst case scenario you'll have to un-install current version and Install a 
specific version.
$\> pip uninstall Django
$\> pip install Django==1.4.14 

More work to upgrade a bunch of virtuaenv's, but not as much as keeping all 
sites current, don't break your eco-system, unless there's a reason.

It's wise to choose a balance best practices that suit your eco-system.

I'd thank the team for issuing security releases for old versions.


-- 
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/1ddd5bbb-b2e6-4791-a92f-96bf997a9e1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Brute force attacks

[shmengie]

Hi Guys,

This topic has me crawling out of the woodwork, I would like to
contribute to the effort.

Can't see this making it into django's core, although I would like to
see it there, I think complexities would inhibit beginners and
veterans alike, although, it would be nice if it could be configured
and enabled.

At a minimum, it's going to require a table or two in the auth realm,
and additional hooks on the rack.

What I would like to see is something akin to a bank's level of
security that could be throttled to preference.


-Joe

-- 
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: dates postgres django trunk

[shmengie]

DOH, I thought I tried changing the DATE_FORMAT and it had no effect.
Seems I checked the wrong server when I checked that.

Thanks, it does fix it when you compare output on the right server.
8-|

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

dates postgres django trunk

[shmengie]

Recently updated to the latest trunk (couple weeks ago now).

I think this may be a bug in the current trunk.

alist = Table_with_date_column.objects.all()


in template:
  {{ alist.date_field }}

renders:

%10/%26/%2009
%07/%22/%2009
...

This must have something to do with the

settings.py
DATE_FORMAT = "%m/%d/%Y"

appears to have no effect.

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