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

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 s

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

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

Re: Proposal: Support for HTTP PATCH method

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

Combine localflavor apps again

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 ap

Re: Combine localflavor apps again

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 lo

Re: Combine localflavor apps again

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 >

Re: Combine localflavor apps again

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

I'm interested in maintaining localflavor-at

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

Re: I'm interested in maintaining localflavor-at

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 unsubscr

Re: I'm interested in maintaining localflavor-at

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

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

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 mess

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

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-

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

+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 willin

Re: Proposal: Support for HTTP PATCH method

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 e

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

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

Re: Combine localflavor apps again

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 fro

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

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 h

Re: Combine localflavor apps again

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 bi

Re: RFC: "universal" view decorators

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

Re: History of datetime_cast_sql() in Oracle

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 s

Re: History of datetime_cast_sql() in Oracle

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

Handling tests in django-localflavor-*

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 p

Re: History of datetime_cast_sql() in Oracle

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

Re: History of datetime_cast_sql() in Oracle

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

Proposal: implement Postgres CLUSTER USING by default for MtM tables

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 |

Re: History of datetime_cast_sql() in Oracle

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