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

On 23 touko, 06:53, Donald Stufft wrote: > So I just submitted a PR for the pre_syncdb > signal:https://github.com/django/django/pull/1200 > > After I get an eye or two on it, assuming no one has any issues with it I'll > merge it. Minor error in docs spotted, otherwise looks

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

On May 21, 2013, at 12:11 PM, peter wrote: > +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 > > :/ > > >

Re: Predicate as suggested new feature to extend url resolver process

Hi Rach -- Thanks for the clarification. I'd like to make three broader points. They may not seem like they're directly addressing your proposal, but stick with me, I promise this comes together to your specific proposal at the end: 1. "But framework X does it like this" isn't a particularly

Re: selecting app for syncdb

Hi Michał, The short answer is "inter-application dependencies". For example, if one application has a foreign key on a second application, and you only synchronise the first application, you won't be able to set up any foreign key constraints on the first application. If you use the project in

Re: Proposal: Support for HTTP PATCH method

Hi Krzysztof, Thanks for that patch -- I've just merged it to trunk. Yours, Russ Magee %-) On Wed, May 22, 2013 at 9:46 PM, Krzysztof Jurewicz < krzysztof.jurew...@gmail.com> wrote: > W dniu 21.05.2013 14:38, Russell Keith-Magee pisze: > > These are all reasonable and fairly small I'd be

Re: Passing parameters to raw()

On Wed, May 22, 2013 at 5:37 PM, Roman Klesel wrote: > Hello, > > > the docs say: > > """ > Passing parameters into raw() > > If you need to perform parameterized queries, you can use the params > argument to raw(): > > >>> lname = 'Doe' > >>> Person.objects.raw('SELECT *

Re: selecting app for syncdb

On Thursday 23 May 2013, Łukasz Langa wrote: > On 23 maj 2013, at 00:52, Shai Berger wrote: > > If I'm not mistaken, there are some problems with the latest released > > version (0.7.6) > > FWIW, the latest released version is 0.8 as of earlier today: > Can't take your eyes

Re: Proposal: implement Postgres CLUSTER USING by default for MtM tables

On May 21, 2013, at 9:28 PM, bry...@obviously.com wrote: > 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

Re: Proposal: implement Postgres CLUSTER USING by default for MtM tables

Hi Bryce, An interesting idea. How are you proposing that this feature be exposed as an API? Is there any reason that this couldn't be handled as a DB-admin operation? i.e., Django just does what it normally does, and if a DB admin notices that table clustering is a problem, they apply the

Re: Predicate as suggested new feature to extend url resolver process

Thanks for the feedback. I assume If it's not use then performance should be the same. But I don't know if the single check for the presence of the attribute or not would affect much the performance. The goal of this feature is offering a hook to allow people extend a bit the routing logic.

Re: Passing parameters to raw()

Hi Roman, On Wednesday 22 May 2013, Roman Klesel wrote: > > howerver this woks just fine and I see no reason why this should not be done: > >>> param = dict(lname = 'Doe') > >>> qs = Person.objects \ > >>>.raw('SELECT * FROM myapp_person WHERE last_name = %(lname)s', param) > This

Re: selecting app for syncdb

On 23 maj 2013, at 00:52, Shai Berger wrote: > If I'm not mistaken, there are some problems with the latest released version > (0.7.6) FWIW, the latest released version is 0.8 as of earlier today: https://pypi.python.org/pypi/South -- Best regards, Łukasz Langa WWW:

Re: selecting app for syncdb

On Thursday 23 May 2013, Michał Nowotka wrote: > I don't and I won't (south is not working with Oracle). This discussion is getting to a place where it belongs either on django-users or south-users; I should point out, though, that South does work with Oracle. If I'm not mistaken, there are

Re: Predicate as suggested new feature to extend url resolver process

I think what Rach is suggesting is different from @require_GET, @require_POST, etc. The patch essentially makes a view invisible if the predicate function returns False. I'm not sure this would be good for inclusion to django, since you are tying url resolution to application state . This could

Re: Predicate as suggested new feature to extend url resolver process

It's different in the way that the view url won't match and the url resolving will continue, where require_GET would raise a django.http.HttpResponseNotAllowed ** I had to change the UrlResolver a bit ** This allow to have same urls which pick the right view base on the state/values of the

Re: Predicate as suggested new feature to extend url resolver process

I'm not sure I understand what you're proposing here. How is this different from @require_GET, @require_POST, and friends? Jacob On Wed, May 22, 2013 at 11:05 AM, Rach Belaid wrote: > I just did a pull request resulting of my last Django sprints for > adding a new

Re: selecting app for syncdb

I don't and I won't (south is not working with Oracle). -- 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

Re: selecting app for syncdb

If you have south installed, I believe you can use migrate which takes an app argument. python manage.py migrate myapp -A On Wed, May 22, 2013 at 12:50 PM, Michał Nowotka wrote: > Hello, > > Is the any particular reason why syncdb doesn't have argument with list of >

selecting app for syncdb

Hello, Is the any particular reason why syncdb doesn't have argument with list of applications to be synced? -- 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

Predicate as suggested new feature to extend url resolver process

I just did a pull request resulting of my last Django sprints for adding a new feature in Django. https://code.djangoproject.com/ticket/20479 The idea is being able to have more control on the url resolving process. I have no merit behind the idea of predicate. Predicate is one of my favorite

Re: Proposal: Support for HTTP PATCH method

W dniu 21.05.2013 14:38, Russell Keith-Magee pisze: 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. I’ve created a ticket and a pull request with PATCH support for View and RedirectView (support for

Passing parameters to raw()

Hello, the docs say: """ Passing parameters into raw() If you need to perform parameterized queries, you can use the params argument to raw(): >>> lname = 'Doe' >>> Person.objects.raw('SELECT * FROM myapp_person WHERE last_name = %s', >>> [lname]) params is a list of parameters. You’ll use

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