Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[charettes]

This makes me wonder if you're planing to introduce a `SOUTH_TEST_MIGRATE` 
setting analog when moving migration handling to core.

I think most people with a huge south migration history will set this 
setting to `False` to speedup testsuite execution and thus they couldn't be 
used for database setup.

Maybe people should just lean toward rebasing their migrations instead?

Le lundi 20 mai 2013 03:20:32 UTC-4, Andrew Godwin a écrit :
>
> Of course, the long-term solution for this is probably migrations. The 
> post_syncdb signal already causes me problems - as there's no good 
> definition for it with migrations around (you basically have to send it 
> right at the end for every model you think you touched).
>
> However, the patch Donald linked would be a lot easier to emulate, so I'm 
> not that against it.
>
> Andrew
>
>
> On Sat, May 18, 2013 at 7:15 PM, Donald Stufft 
> > wrote:
>
>> There's already a patch on the ticket tracker for a pre_syncdb signal, 
>> and yesterday I started updating it and modifying it a bit as I needed this 
>> signal.
>>
>> https://github.com/dstufft/django/compare/pre-syncdb-signal
>>
>> On May 18, 2013, at 1:06 PM, Karol Sikora > 
>> wrote:
>>
>> I can try to implement approach with pre_syncdb signal tomorrow. I think 
>> that is quite enough solution before deeper diggling into new migrations 
>> framework.
>>
>> Karol
>> 18 maj 2013 19:03, "Anssi Kääriäinen" > 
>> napisał(a):
>>
>>> On 16 touko, 11:20, Danilo Bargen  wrote:
>>> > As a sidenote, there was a discussion about this on this mailing list 
>>> a few
>>> > months ago:
>>> >
>>> > https://groups.google.com/forum/#!searchin/django-developers/16550/dj.
>>> ..
>>>
>>> I think a pre_sync signal is best approach. The signal should be
>>> called either just after connecting to the (test) DB in syncdb
>>> command, or maybe just after existing tables have been introspected so
>>> that you know what tables are already there. Latter might be better as
>>> syncdb can be ran multiple times, and you only need to CREATE
>>> EXTENSION on initial sync. OTOH if you add one more model with
>>> JSONField it seems you would need to run another CREATE EXTENSION, or
>>> to investigate if some existing model has already ran CREATE
>>> EXTENSION. So, defensive coding (that is, CREATE EXTENSION IF NOT
>>> EXISTS) would be needed.
>>>
>>> Another problem is that post_syncdb is called from flush command, too.
>>> This seems wrong. Could we just add post_flush signal and send that
>>> instead? Another option is to add a "for_flush" kwarg to the signal
>>> parameters, but it feels just so wrong to have post_syncdb signal with
>>> an argument that tells syncdb didn't happen after all. The reason for
>>> post_syncdb from flush is creation of ContentTypes and Permissions
>>> after truncation of those tables.
>>>
>>> While the pre_syncdb signal approach has many shortcomings (how to
>>> include the output in sqlall?), I think it is enough to solve this
>>> problem for now. You can run CREATE EXTENSION IF NOT EXISTS and that
>>> seems already a big step forward. Also, distinguishing post_flush from
>>> post_syncdb seems like a good idea, but should be done in separate
>>> ticket.
>>>
>>> Later on migrations framework could offer a much better solution to
>>> this. But pre_syncdb signal seems small enough to include already in
>>> 1.6. Maybe this could be done in the sprints?
>>>
>>>  - 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-develop...@googlegroups.com .
>>> To post to this group, send email to 
>>> django-d...@googlegroups.com
>>> .
>>> Visit this group at 
>>> http://groups.google.com/group/django-developers?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>>
>>  
>> -
>> Donald Stufft
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
>> DCFA
>>  
>>
>

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

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Donald Stufft]

I run migrations in test. How else will you know your db reflects reality :/

On May 20, 2013, at 10:58 AM, charettes  wrote:

> This makes me wonder if you're planing to introduce a `SOUTH_TEST_MIGRATE` 
> setting analog when moving migration handling to core.
> 
> I think most people with a huge south migration history will set this setting 
> to `False` to speedup testsuite execution and thus they couldn't be used for 
> database setup.
> 
> Maybe people should just lean toward rebasing their migrations instead?
> 
> Le lundi 20 mai 2013 03:20:32 UTC-4, Andrew Godwin a écrit :
>> 
>> Of course, the long-term solution for this is probably migrations. The 
>> post_syncdb signal already causes me problems - as there's no good 
>> definition for it with migrations around (you basically have to send it 
>> right at the end for every model you think you touched).
>> 
>> However, the patch Donald linked would be a lot easier to emulate, so I'm 
>> not that against it.
>> 
>> Andrew
>> 
>> 
>> On Sat, May 18, 2013 at 7:15 PM, Donald Stufft  wrote:
>>> There's already a patch on the ticket tracker for a pre_syncdb signal, and 
>>> yesterday I started updating it and modifying it a bit as I needed this 
>>> signal.
>>> 
>>> https://github.com/dstufft/django/compare/pre-syncdb-signal
>>> 
>>> On May 18, 2013, at 1:06 PM, Karol Sikora  wrote:
>>> 
 I can try to implement approach with pre_syncdb signal tomorrow. I think 
 that is quite enough solution before deeper diggling into new migrations 
 framework.
 
 Karol
 
 18 maj 2013 19:03, "Anssi Kääriäinen"  napisał(a):
> On 16 touko, 11:20, Danilo Bargen  wrote:
> > As a sidenote, there was a discussion about this on this mailing list a 
> > few
> > months ago:
> >
> > https://groups.google.com/forum/#!searchin/django-developers/16550/dj...
> 
> I think a pre_sync signal is best approach. The signal should be
> called either just after connecting to the (test) DB in syncdb
> command, or maybe just after existing tables have been introspected so
> that you know what tables are already there. Latter might be better as
> syncdb can be ran multiple times, and you only need to CREATE
> EXTENSION on initial sync. OTOH if you add one more model with
> JSONField it seems you would need to run another CREATE EXTENSION, or
> to investigate if some existing model has already ran CREATE
> EXTENSION. So, defensive coding (that is, CREATE EXTENSION IF NOT
> EXISTS) would be needed.
> 
> Another problem is that post_syncdb is called from flush command, too.
> This seems wrong. Could we just add post_flush signal and send that
> instead? Another option is to add a "for_flush" kwarg to the signal
> parameters, but it feels just so wrong to have post_syncdb signal with
> an argument that tells syncdb didn't happen after all. The reason for
> post_syncdb from flush is creation of ContentTypes and Permissions
> after truncation of those tables.
> 
> While the pre_syncdb signal approach has many shortcomings (how to
> include the output in sqlall?), I think it is enough to solve this
> problem for now. You can run CREATE EXTENSION IF NOT EXISTS and that
> seems already a big step forward. Also, distinguishing post_flush from
> post_syncdb seems like a good idea, but should be done in separate
> ticket.
> 
> Later on migrations framework could offer a much better solution to
> this. But pre_syncdb signal seems small enough to include already in
> 1.6. Maybe this could be done in the sprints?
> 
>  - 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
 
 
 -- 
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-developers?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.
>>> 
>>> 
>>> -
>>> Donald Stufft
>>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
> -- 
> 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

Re: Proposal: Support for HTTP PATCH method

[Russell Keith-Magee]

Hi Krzysztof

On Mon, May 20, 2013 at 7:48 PM, Krzysztof Jurewicz <
krzysztof.jurew...@gmail.com> wrote:

> There is a RFC describing HTTP method named PATCH:
>
> http://tools.ietf.org/html/**rfc5789 
>
> Quoting that RFC:
> “  The difference between the PUT and PATCH requests is reflected in the
>way the server processes the enclosed entity to modify the resource
>identified by the Request-URI.  In a PUT request, the enclosed entity
>is considered to be a modified version of the resource stored on the
>origin server, and the client is requesting that the stored version
>be replaced.  With PATCH, however, the enclosed entity contains a set
>of instructions describing how a resource currently residing on the
>origin server should be modified to produce a new version.”
>
> Django currently has (seemingly shallow) support for PUT method. Based on
> that, I’ve grepped for places in code where it is implemented to see if
> support for PATCH could be easily added on a basis of symmetry. Those
> places are:
>
> In test client:
> There is a `put` method, but `patch` is also implemented:
> https://github.com/django/**django/commit/**293f7a21147ad94c92c7d5b3f33cba
> **b2f87b001b
>
> In View class:
> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d**
> 73b9d46476/django/views/**generic/base.py#L33
> `put` is listed in http_method_names
>
> In RedirectView:
> `put` is a fallback to .get():
> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d**
> 73b9d46476/django/views/**generic/base.py#L207
>
> In ProcessFormView:
> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d**
> 73b9d46476/django/views/**generic/edit.py#L164
> PUT is implemented as a fallback to POST and it seems to assume that
> request data is form encoded. While it is not generally true for PUT
> method, it looks like a reasonable assumption when processing a form.
> However since PATCH request doesn’t have to contain full form data, I think
> the best approach may be to not implement `patch` method here (unless we
> want to deal with editing only some of the form’s fields – for example this
> is the case in Rails, where PATCH will be the primary method for updates in
> 4.0 version: http://weblog.rubyonrails.org/**
> 2012/2/25/edge-rails-patch-is-**the-new-primary-http-method-**for-updates/).
>  The same stays true to `get_form_kwargs` method in FormMixin:
> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d**
> 73b9d46476/django/views/**generic/edit.py#L44
> In general, Django’s approach to whether PUT should be treated as a
> request containing form data seems to be inconsistent because we generate
> forms in the views, but we refuse to generate PUT QueryDict on a request
> object: https://groups.google.com/d/**msg/django-developers/**
> dxI4qVzrBY4/m_9IiNk_p7UJ.
>  So maybe it’s worth to consider removing PUT support in form processing
> just on the basis of consistency.
>
> In conclusion, it seems pretty easy to add basic PATCH support similar to
> PUT. So if it gets enough +1s, I’m willing to make a patch and hope it gets
> included in 1.6 alpha. Or maybe it is (from a technical point of view) so
> small a feature that it doesn‘t need to be merged before alpha release?
>

These are all reasonable and fairly small I'd be happy to see these added
after the alpha - a ticket and patch would definitely be welcome.

The only one that is even remotely controversial to me is the handling of
PATCH in ProcessFormView. I agree that there are potential problems with
using PUT as an analog of POST, but it largely works in this situation; so
I don't know if it's worth deprecating the PUT->POST fallback in this case.

Strictly, I think it's actually a separate issue -- the first three points
you raise are about allowing PATCH at all; the last point is about how we
should deal with PATCH in a specific case. Once the first two items on your
list are addressed, it would be possible to implement a patch() method on
your own generic view subclass; the question is what Django should be doing
as a project to make that implementation easier/more useful.

Yours,
Russ Magee %-)

-- 
You received this message because you are 

Combine localflavor apps again

[Jannis Leidel]

Hi all,

I'd like propose to combine all the django-localflavor-* packages - that were 
moved out of contrib a while ago - into a new "django-localflavor" package. 
None of the current maintainers would lose the commit bit. I'm ready to do the 
heavy lifting for that.

Ever since the localflavor apps were removed from contrib I've seen many stale 
ones, lingering on Github, only collecting issues and pull requests, without 
much guidance. We have been missing maintainers since the removal from contrib, 
even if some of the core developers helped out every once in a while. Recently 
we added a few more maintainers for each of those packages since they asked for 
it, which is great. But frankly I think that's not enough. Up until now only 7 
of the 44 localflavor on github.com/django have been re-released on PyPI as 
separate packages. In other words, we have a success rate of handing over the 
maintainership of ~15%. I think that's because there is a lot of maintenance 
friction for each package.

With the split in packages we also broke the maintenance of translations of 
those localflavors, by removing those apps from the previously well established 
workflow using Transifex and left it to the maintainers to find a way. 
Especially for that kind of app a rather glaring mistake, IMO.

We also stopped being able to re-use code between localflavors, for example 
cryptographic code about ID validation, which in my opinion is a security 
liability that alone should be reason enough to have only one package.

There was also never a clear plan for releasing or deprecation of localflavor 
packages, which is the opposite to what we've been doing in the past with our 
release policy.

So what I propose to fix this is simple:

- combine the localflavor packages into one Python package again, call it 
django-localflavor
- give all the individual country maintainers also access to that package
- have a central documentation, e.g. django-localflavor.readthedocs.org
- update the Django docs to point to that package
- ask the maintainers of the 7 already released packages to point to the newly 
created django-localflavor

What do you think?

Jannis

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

Re: Combine localflavor apps again

[Aymeric Augustin]

2013/5/21 Jannis Leidel 

> I'd like propose to combine all the django-localflavor-* packages - that
> were moved out of contrib a while ago - into a new "django-localflavor"
> package. None of the current maintainers would lose the commit bit. I'm
> ready to do the heavy lifting for that.


I'd love to see localflavor in a better shape, even though I don't have
strong opinions on what should be done.

The situation would certainly be less dire if we had looked for
maintainers. Did we say clearly that we wanted to hand over the
repositories to local maintainers?

Merging the repositories again will require a non-negligible amount of work
and a second migration for users who already started using
django_localflavor_xx.

However, if you're convinced that's the right thing to do at this point, I
don't oppose that move. It would help maintain best practices, especially
wrt. backwards-compatibility and testing.

-- 
Aymeric.

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

Re: Combine localflavor apps again

[Łukasz Langa]

On 21 maj 2013, at 14:51, Jannis Leidel  wrote:

> - combine the localflavor packages into one Python package again, call it 
> django-localflavor
> - give all the individual country maintainers also access to that package
> - have a central documentation, e.g. django-localflavor.readthedocs.org
> - update the Django docs to point to that package
> - ask the maintainers of the 7 already released packages to point to the 
> newly created django-localflavor
> 
> What do you think?


+1

This will make handling backwards compatibility easier, especially by having a 
central deprecation policy on outdated or invalid data in separate 
localflavors. Users have the right to know when compatibility might break and 
when a fix is going to get deployed. Such a combination will also enable users 
to use a flavor that lacks a formal maintainer.

Just $0.02 from the just-proclaimed django-localflavor-pl maintainer.

-- 
Best regards,
Łukasz Langa

WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev

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

Re: Combine localflavor apps again

[Donald Stufft]

On May 21, 2013, at 8:51 AM, Jannis Leidel  wrote:

> Hi all,
> 
> I'd like propose to combine all the django-localflavor-* packages - that were 
> moved out of contrib a while ago - into a new "django-localflavor" package. 
> None of the current maintainers would lose the commit bit. I'm ready to do 
> the heavy lifting for that.
> 
> Ever since the localflavor apps were removed from contrib I've seen many 
> stale ones, lingering on Github, only collecting issues and pull requests, 
> without much guidance. We have been missing maintainers since the removal 
> from contrib, even if some of the core developers helped out every once in a 
> while. Recently we added a few more maintainers for each of those packages 
> since they asked for it, which is great. But frankly I think that's not 
> enough. Up until now only 7 of the 44 localflavor on github.com/django have 
> been re-released on PyPI as separate packages. In other words, we have a 
> success rate of handing over the maintainership of ~15%. I think that's 
> because there is a lot of maintenance friction for each package.
> 
> With the split in packages we also broke the maintenance of translations of 
> those localflavors, by removing those apps from the previously well 
> established workflow using Transifex and left it to the maintainers to find a 
> way. Especially for that kind of app a rather glaring mistake, IMO.
> 
> We also stopped being able to re-use code between localflavors, for example 
> cryptographic code about ID validation, which in my opinion is a security 
> liability that alone should be reason enough to have only one package.
> 
> There was also never a clear plan for releasing or deprecation of localflavor 
> packages, which is the opposite to what we've been doing in the past with our 
> release policy.
> 
> So what I propose to fix this is simple:
> 
> - combine the localflavor packages into one Python package again, call it 
> django-localflavor
> - give all the individual country maintainers also access to that package
> - have a central documentation, e.g. django-localflavor.readthedocs.org
> - update the Django docs to point to that package
> - ask the maintainers of the 7 already released packages to point to the 
> newly created django-localflavor
> 
> What do you think?
> 
> Jannis
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 


This sounds ok to me.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

I'm interested in maintaining localflavor-at

[Horst Gutmann]

Hi :-)

If nobody else volunteers, I'd like to help by maintaining the
localflavor-at package.

First working order should be to get it it somehow onto PyPI (depending
on the outcome of Jannis' proposal).

Username on IRC and Github: zerok

Best wishes,
Horst

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

Re: I'm interested in maintaining localflavor-at

[Aymeric Augustin]

2013/5/21 Horst Gutmann 


> If nobody else volunteers, I'd like to help by maintaining the
> localflavor-at package.
>

You now have commit access. Welcome on board!

-- 
Aymeric.

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

Re: I'm interested in maintaining localflavor-at

[Horst Gutmann]

Thank you :-)

> Aymeric Augustin 
> May 21, 2013 5:10 PM
> 2013/5/21 Horst Gutmann mailto:ho...@zerokspot.com>>
>  
>
> If nobody else volunteers, I'd like to help by maintaining the
> localflavor-at package.
>
>
> You now have commit access. Welcome on board! 
>
> -- 
> Aymeric.
> -- 
> You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
> Horst Gutmann 
> May 21, 2013 4:26 PM
> Hi :-)
>
> If nobody else volunteers, I'd like to help by maintaining the
> localflavor-at package.
>
> First working order should be to get it it somehow onto PyPI (depending
> on the outcome of Jannis' proposal).
>
> Username on IRC and Github: zerok
>
> Best wishes,
> Horst

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

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Shai Berger]

On Tuesday 21 May 2013, Donald Stufft wrote:
> I run migrations in test. How else will you know your db reflects reality
> :/
> 

When you have a few hundred migrations, that's something you're willing to do 
in your CI server, but not on your development machine.

Shai.

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

Re: first() and last(), earliest() and latest()

[Anssi Kääriäinen]

I just pushed the patch to master. I didn't do anything to the API in
the latest pull. No only=True or .only(), and earliest() and latest()
still exist. I didn't feel like bikeshedding this issue any more.

I am happy that we now have some way to get single object from a
queryset without using try-except.

Thanks to all who contributed!

 - Anssi

On 17 touko, 02:29, Selwin Ong  wrote:
> Hi Shai,
>
> We can add args and kwargs later when it's actually needed, it's not needed 
> right now and it' cleaner, I think.
>
> As for "only=True", these methods are meant to replace "latest()". If someone 
> ones to ensure that the queryset returns only one object,  I dont think 
> "Queryset.get()" is going anywhere soon so they should use that. Besides, 
> "first()" and "last()" don't really make sense if you expect a queryset to 
> only return a single object - ordering doesn't matter.
>
> That's just what I think though.
>
> Best,
> Selwin

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

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[peter]

+1 on pre_syncdb

On Tuesday, May 21, 2013 8:29:49 AM UTC-7, Shai Berger wrote:
>
> On Tuesday 21 May 2013, Donald Stufft wrote: 
> > I run migrations in test. How else will you know your db reflects 
> reality 
> > :/ 
> > 
>
> When you have a few hundred migrations, that's something you're willing to 
> do 
> in your CI server, but not on your development machine. 
>
> Shai. 
>

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

Re: Proposal: Support for HTTP PATCH method

[Tom Christie]

I'm basically in agreement with Russ here.

I'd consider the first three points as being non-controversial.

With regards to ProcessFormView I think implementing a put() method, but 
not a patch() method falls squarely into the 'good-enough' category of 
behavior.  In any case, although there are existing conventions, the exact 
semantics of PATCH requests are a little vague[*], and the generic view's 
handling of PUT/PATCH is of fairly limited use, given that they only 
support form-encoded data, and not, say JSON data. Given that, I don't 
think we need to get too hung up on correctness in that particular area.

Cheers,

  Tom

[*]: As an example Ember's `json-api` style uses RFC 6902, which is more 
involved than most conventional implementations of PATCH: 
http://tools.ietf.org/html/rfc6902


On Tuesday, 21 May 2013 13:38:15 UTC+1, Russell Keith-Magee wrote:
>
> Hi Krzysztof
>
> On Mon, May 20, 2013 at 7:48 PM, Krzysztof Jurewicz <
> krzysztof...@gmail.com > wrote:
>
>> There is a RFC describing HTTP method named PATCH:
>>
>> http://tools.ietf.org/html/**rfc5789 
>>
>> Quoting that RFC:
>> “  The difference between the PUT and PATCH requests is reflected in the
>>way the server processes the enclosed entity to modify the resource
>>identified by the Request-URI.  In a PUT request, the enclosed entity
>>is considered to be a modified version of the resource stored on the
>>origin server, and the client is requesting that the stored version
>>be replaced.  With PATCH, however, the enclosed entity contains a set
>>of instructions describing how a resource currently residing on the
>>origin server should be modified to produce a new version.”
>>
>> Django currently has (seemingly shallow) support for PUT method. Based on 
>> that, I’ve grepped for places in code where it is implemented to see if 
>> support for PATCH could be easily added on a basis of symmetry. Those 
>> places are:
>>
>> In test client:
>> There is a `put` method, but `patch` is also implemented:
>> https://github.com/django/**django/commit/**
>> 293f7a21147ad94c92c7d5b3f33cba**b2f87b001b
>>
>> In View class:
>> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d*
>> *73b9d46476/django/views/**generic/base.py#L33
>> `put` is listed in http_method_names
>>
>> In RedirectView:
>> `put` is a fallback to .get():
>> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d*
>> *73b9d46476/django/views/**generic/base.py#L207
>>
>> In ProcessFormView:
>> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d*
>> *73b9d46476/django/views/**generic/edit.py#L164
>> PUT is implemented as a fallback to POST and it seems to assume that 
>> request data is form encoded. While it is not generally true for PUT 
>> method, it looks like a reasonable assumption when processing a form. 
>> However since PATCH request doesn’t have to contain full form data, I think 
>> the best approach may be to not implement `patch` method here (unless we 
>> want to deal with editing only some of the form’s fields – for example this 
>> is the case in Rails, where PATCH will be the primary method for updates in 
>> 4.0 version: http://weblog.rubyonrails.org/**
>> 2012/2/25/edge-rails-patch-is-**the-new-primary-http-method-**
>> for-updates/).
>>  The same stays true to `get_form_kwargs` method in FormMixin:
>> https://github.com/django/**django/blob/**a93672622829e0d4a2ff3240456d4d*
>> *73b9d46476/django/views/**generic/edit.py#L44
>> In general, Django’s approach to whether PUT should be treated as a 
>> request containing form data seems to be inconsistent because we generate 
>> forms in the views, but we refuse to generate PUT QueryDict on a request 
>> object: https://groups.google.com/d/**msg/django-developers/**
>> dxI4qVzrBY4/m_9IiNk_p7UJ.
>>  So maybe it’s worth to consider removing PUT support in form processing 
>> just on the basis of consistency.
>>
>> In conclusion, it seems pretty easy to add basic PATCH support similar to 
>> PUT. So if it gets enough +1s, I’m willing to make a patch and hope it gets 
>> included in 1.6 alpha. Or maybe it is (from a technical point of view) so 
>> small a feature that it doesn‘t need to be merged before al

Re: I am interested in maintaining django-localflavor-us

[Jacob Kaplan-Moss]

OK, you should be good to go.

Jacob

On Mon, May 20, 2013 at 11:54 PM, Trey Hunner  wrote:
> I'm treyhunner on Github.  Thanks Jacob.
>
>
> On Monday, May 20, 2013 3:14:59 PM UTC-7, Jacob Kaplan-Moss wrote:
>>
>> No objections from me. What's your GitHub username? I'll hook you up.
>>
>> Jacob
>>
>> On Mon, May 20, 2013 at 3:10 PM, Trey Hunner  wrote:
>> > The django-localflavor-us package currently lacks a responsive
>> > maintainer.  I would like to fix this problem by helping to maintain
>> > this project.
>> >
>> > My primary goals:
>> >
>> > * Make the tests easier to run
>> > * Merge good pull requests
>> > * Add instructions for contributing (namely how to run the tests)
>> > * Ensure the project stays up-to-date on PyPI
>> >
>> > I already uploaded the project to PyPI.  I can't help much more
>> > currently without commit access or someone with commit access to
>> > comment on and merge pull requests.
>> >
>> > --
>> > Trey Hunner
>> >
>> > --
>> > 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-develop...@googlegroups.com.
>> > To post to this group, send email to django-d...@googlegroups.com.
>> > Visit this group at
>> > http://groups.google.com/group/django-developers?hl=en.
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

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

Re: Combine localflavor apps again

[Jacob Kaplan-Moss]

On Tue, May 21, 2013 at 7:51 AM, Jannis Leidel  wrote:
> What do you think?

I have no opinions either way, happy to help out if this is the
direction you want to go.

Jacob

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

Re: first() and last(), earliest() and latest()

[Jacob Kaplan-Moss]

On Tue, May 21, 2013 at 10:45 AM, Anssi Kääriäinen
 wrote:
> I just pushed the patch to master. I didn't do anything to the API in
> the latest pull. No only=True or .only(), and earliest() and latest()
> still exist. I didn't feel like bikeshedding this issue any more.
>
> I am happy that we now have some way to get single object from a
> queryset without using try-except.

Woohoo, thanks!

Jacob

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

Re: Combine localflavor apps again

[ptone]

On Tuesday, May 21, 2013 5:51:11 AM UTC-7, Jannis Leidel wrote:
>
> Hi all, 
>
> I'd like propose to combine all the django-localflavor-* packages - that 
> were moved out of contrib a while ago - into a new "django-localflavor" 
> package. None of the current maintainers would lose the commit bit. I'm 
> ready to do the heavy lifting for that. 
>
>
>  

>
> What do you think? 
>

Clearly the current fragmentation has proven unworkable, so I think there 
is only upside in trying this approach.

I think there needs to be someone who will coordinate the version bumps and 
releases to PyPI  - perhaps just document that it will be released n times 
per year on dates a, b, c, d - and just roll whatever changes make it in by 
those dates? Maybe you are volunteering for that as well ;-)

so +1 from me.

-Preston

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

Re: RFC: "universal" view decorators

[ptone]

On Saturday, May 18, 2013 5:57:49 AM UTC-7, Marc Tamlyn wrote:
>
> I'm going to resurrect this old thread as I'd like to get it resolved in 
> some fashion.
>
> I used to be very in favour of the class decorators approach. I've been 
> using an implementation of `@class_view_decorator(func)` for some time and 
> it works pretty well. That said my implementation at least was subject to a 
> notable flaw which is that if multiple parts of the hierarchy have the same 
> decorator applied to them then the check gets done twice. Mixins are much 
> cleverer than this because of MRO, so we avoid that problem.
>
> Mixins however have their own issues - it's "harder" (for some definition) 
> to ensure that all of your top-level permission checking happening in the 
> correct order. That said, I am certainly veering towards implementing this 
> using mixins (for each piece of functionality).
>
> I'd really like to have a look at Donald's implementation, sadly it seems 
> to no longer be on github. Do you still have then code somewhere, or can 
> you explain the implementation idea?
>

Marc, ask and you shall receive.

I've always been convinced this is the way to go:

https://github.com/ptone/django/compare/mixin-decorators

-P
 

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

Re: History of datetime_cast_sql() in Oracle

[Aymeric Augustin]

On 19 mai 2013, at 15:33, Shai Berger  wrote:

> I was able to track the history of this function, into the mists of time. In 
> the beginning, code to cast strings into dates for Oracle was mixed in with 
> the general querying code. Then came the boulder-oracle-sprint of 2006-2007, 
> where, at some point, that piece of code was factored out to a module-level 
> function get_datetime_cast_sql(), which was defined in all backends as a 
> no-op 
> except Oracle; this was later refactored into the DatabaseOperations class we 
> know today.
> 
> However, at about the same time that the DatabaseOperations was created, the 
> Oracle backend made another change: It started setting the session's datetime 
> format on login. This, as far as I understand, makes the special casting 
> operation redundant -- and current test results support my understanding.
> 
> So -- I want to fix, now, the thing that was, well, not broken, but bent, in 
> 2007. And my question to you -- especially, those of you who participated in 
> the boulder sprint -- can you think of any reason why I shouldn't?

Based on the impressive amount of research you've performed, and on the
facts you've found, I think you can go ahead and simplify the code.

I'll review the patch if you want. Thanks for working on this.

-- 
Aymeric.

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

Re: History of datetime_cast_sql() in Oracle

[Ian Kelly]

On Sun, May 19, 2013 at 7:33 AM, Shai Berger  wrote:
> Hi,
>
> In my quest to solve Oracle bugs, I found the function datetime_cast_sql() in
> the Oracle backend. It causes a problem these days, because it gets in the way
> of querying a date as string (mydate__startswith='2005'). It is a function
> that is defined as a no-op in the base backend, and overridden, among core
> backends, only in Oracle. Removing the override, currently, just makes one
> more test pass, and if we decide to remove it from the base, code in several
> other places may become simpler (will not need to special-case datetime
> values).
>
> I was able to track the history of this function, into the mists of time. In
> the beginning, code to cast strings into dates for Oracle was mixed in with
> the general querying code. Then came the boulder-oracle-sprint of 2006-2007,
> where, at some point, that piece of code was factored out to a module-level
> function get_datetime_cast_sql(), which was defined in all backends as a no-op
> except Oracle; this was later refactored into the DatabaseOperations class we
> know today.
>
> However, at about the same time that the DatabaseOperations was created, the
> Oracle backend made another change: It started setting the session's datetime
> format on login. This, as far as I understand, makes the special casting
> operation redundant -- and current test results support my understanding.
>
> So -- I want to fix, now, the thing that was, well, not broken, but bent, in
> 2007. And my question to you -- especially, those of you who participated in
> the boulder sprint -- can you think of any reason why I shouldn't?

You may be right.  One thing I would be concerned about is the
reliability of only doing implicit date conversions.  If you google
for "ORA-01843" you can find a good number of forum posts that
recommend against relying on the NLS_TIMESTAMP_FORMAT setting.  See
also Django ticket #20292.

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

Handling tests in django-localflavor-*

[Horst Gutmann]

Hi :-)

I'm currently looking through the test-integration of the localflavor
packages and due to the structure used here it looks like (as Erik found
out before me) it kind of lends itself to something like nose as testrunner.

For this we both integrated test_settings module into the respective
packages.

Given that the execution of the tests itself isn't really covered by
this alone I was also thinking about adding a tox.ini file to the
package testing it with whatever versions of Python and Django are still
officially supported.

Given that Django itself externalizes multi-variant testing to Jenkins
I'd like to know if adding the tox.ini would be acceptable to you :-)

Cheers,
Horst

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

Re: History of datetime_cast_sql() in Oracle

[Shai Berger]

Hi Ian,

Thanks for your insights.

On Tuesday 21 May 2013 23:22:14 Ian Kelly wrote:
> 
> You may be right.  One thing I would be concerned about is the
> reliability of only doing implicit date conversions.  If you google
> for "ORA-01843" you can find a good number of forum posts that
> recommend against relying on the NLS_TIMESTAMP_FORMAT setting.

I looked at some of those. Most of them warn against it on two grounds:

- The actual format may be different from what you expect
- Formats that use the MON specifier are actually language-dependent

Both of these are mostlly irrelevant for Django -- we set the timestamp format 
explicitly, and we don't use MON. A user may change the date/timestamp format 
via raw sql, and cause breakage (especially with the new persistent 
connections), but -- given the history where we set the format on every 
connection -- I think such users mostly deserve what they get. At most, we 
should warn against it in the documentation.

> See also Django ticket #20292.

Comment #3 on that ticket suggests that explicit casts do little to improve 
things there -- apparently Oracle 10 has a problem applying formats to unicode 
strings. I don't have Oracle 10 accessible to test against, and Django's tests 
include instances of saving models with DateFields -- so I know the problem 
(as reported) is not reproducible against Oracle 11. So as far as I can see, 
removing the explicit cast makes things no worse here too.

I just committed the removal in Oracle.

Thanks,
Shai.

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

Re: History of datetime_cast_sql() in Oracle

[Shai Berger]

On Tuesday 21 May 2013 22:11:02 Aymeric Augustin wrote:
> On 19 mai 2013, at 15:33, Shai Berger  wrote:
> > 
> > So -- I want to fix, now, the thing that was, well, not broken, but bent,
> > in 2007. And my question to you -- especially, those of you who
> > participated in the boulder sprint -- can you think of any reason why I
> > shouldn't?
> 
> Based on the impressive amount of research you've performed, and on the
> facts you've found, I think you can go ahead and simplify the code.
> 

My understanding is that an overridable method in the base DatabaeOperations 
constitutes a public interface (for 3rd party backends). It is not documented, 
so I guess we can get away with skipping deprecation cycles; but don't you 
think we should try to warn users who override it that it is no longer used?

> I'll review the patch if you want. Thanks for working on this.

Thanks, I think I'll call you up on that one. For now, I just removed the 
Oracle override, to let it pass some more tests.

Have fun,
Shai.

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

Proposal: implement Postgres CLUSTER USING by default for MtM tables

[bryce2]

The tables created by django for MtM fields are unordered.  Loading all the 
relationships may result in a number of I/O operations approaching the 
number of relationships:

# select * from basetable;
 id |basetable_id| mtm_id 
++--
  6 |  3 |1
  7 |  2 |2
 15 |  1 |1
 16 |  1 |2
 18 |  3 |5


Postgres has a feature to 'defragment' such tables packing data that gets 
accessed at the same time into the same disk blocks.  The number of I/O 
operations can be as small as one:

# \pset pager off
# cluster basetable using table_mem_id;
# select * from basetable;

 id |basetable_id| mtm_id 
++--
 15 |  1 |1
 16 |  1 |2
  7 |  2 |2
  6 |  3 |1
 18 |  3 |5

On a large table this can put hundreds of MtM relationships sequentially on 
disk.  This makes for less I/O operations and less cache space used.


This feature is postgres specific.
And it would involve django making a guess about the use pattern of the 
relationship.  Either the forward or reverse is optimized.

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

Re: History of datetime_cast_sql() in Oracle

[Aymeric Augustin]

On 22 mai 2013, at 01:32, Shai Berger  wrote:

> I guess we can get away with skipping deprecation cycles; but don't you 
> think we should try to warn users who override it that it is no longer used?

We don't really have a process for that. Maintaining a database backend
for Django is a hard task :-/

-- 
Aymeric.




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