Re: Passing parameters to raw()

[VernonCole]

Officially (according to PEP-249) you are not supposed to be able to do 
that (pass a dictionary  of parameters), but PostgreSQL does it as an 
extension to the spec.  SQLite and ms-sql (both of which use format 
converters to send your queries out with '?' where you put the '%s') do NOT 
support it.  Shai is supplying a patch for Oracle (which uses a different 
format conversion) to support it.
 
There is a very noisy discussion taking place right now on the DB-SIG about 
the design of a future db-api version 3.  I am suggesting that we support 
automatic switching (similar to what you want to use here) but at the 
moment, I am loosing, and I do not expect that it will happen.  So you can 
do that now, on some databases, but do not expect it to be either universal 
or future proof.  I would advise sticking with a list of parameters for 
your present development efforts.

On Wednesday, May 22, 2013 3:37:55 AM UTC-6, roman 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 * FROM myapp_person WHERE last_name = %s', 
> [lname]) 
>
> params is a list of parameters. You’ll use %s placeholders in the 
> query string (regardless of your database engine); they’ll be replaced 
> with parameters from the params list. 
> """ 
>
> 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) 
>
> however still this fails: 
>
> >>> repr(qs) 
> /home/user/vpy/dev/lib/python2.7/site-packages/django/db/models/query.pyc 
> in __repr__(self) 
>1530 
>1531 def __repr__(self): 
> -> 1532 return "" % (self.raw_query % 
> tuple(self.params)) 
>1533 
>1534 def __getitem__(self, k): 
>
> TypeError: format requires a mapping 
>
> If no one objects, I could write a patch to the code and the docs that 
> implements the functionality. 
>
> Regards Roman 
>

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

[Anssi Kääriäinen]

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 good to me.

I am thinking of adding a "for_action" kwarg for post_syncdb.
Currently there is no way to distinguish between flush and syncdb.
This makes it impossible to use the signal for schema changes. I guess
the kwarg could be useful for migrations, too.

Does this sound reasonable? Would the for_action kwarg help with
South?

The pre_syncdb signal isn't sent for flush. I think this is correct,
as I can't see anything you could do in pre_syncdb signal for flush.
If there are use cases, then I think adding for_action to pre_syncdb
should be done. IMO we can do these minor changes after alpha if need
be.

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

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 
> > :/ 
> > 
> 
> 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.
>  
>  


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.

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



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Jacob Kaplan-Moss]

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 good
argument for why *Django* should do something. Yes, it's important to
understand and follow what's going on in the greater web world, and
yes it's important to beg, borrow, and steal good ideas. But you have
to articulate why an idea is *good for Django*. After all, if we
wanted to be just like Framework X, we'd all just be using Framework
X. In many ways the high quality of our competitors actually frees us
up to be *more* skeptical of what we add to Django. We don't *need* to
be more like other frameworks because those other frameworks are
usually *great* -- if you like them, you should use them! We should be
focusing on doing the things we're good at. Let Django be Django.

2. One of the really high bars you have to clear when you propose new
things for Django is the bar of utility. It's not good enough to
demonstrate that something's a good idea. It's not good enough to
demonstrate that it solves your problem. It's not even good enough to
demonstrate that it solves some bigger problem. You have to
demonstrate that what you're proposing is so useful that a sizable
portion of people using Django would be excited by your new thing. One
of Django's real strengths is its stability, but the cost of that
strength is that we say "no" a lot.

3. Flexibility is a very important goal. Our philosophy of "sensible
defaults" doesn't mean that the default choice should be the only
choice! It means that we should provide a reasonable default for most
people, but then give people "escape hatches" when those defaults
don't quite work out.

So given these principles, let's look at your proposal again:

1. Much of your argument seems to come down to "Pyramid does it this
way." It does, and it's a good match… for Pyramid. You haven't
articulated why this is a good addition *for Django*, and I think
that's because it isn't. Django's @require_POST and friends are
simple, obvious, and easy to understand, whereas this predicate
business adds another layer of complexity. Further, it violates one of
the cardinal design points of the routing system, which is that all
the information you need to figure out routing should be in the routes
file. Pushing routing logic down into the views -- which is what your
proposal does -- violates this basic tenant of Django. That design is
pretty close to set in stone; you're going to need a very excellent
argument to change a design choice that's been in place for nearly a
decade now.

2. One of the ways you might win that argument would be by arguing
massive utility for a large segment of Django's user base. Again,
though, we already have this feature implemented in a more
"Django-esque" way, so I don't really buy that argument.

3. Ah, but there is something deeper here worth looking at. URL
routing is one of the *least* flexible parts of Django. It's possible
to customize routing (see https://github.com/jacobian/django-multiurl
for one example), but it's rather complicated and relies on a pretty
deep understanding of how routing works. That's bad; it should be
easier to add these sorts of things if you choose *without* needing to
add something new to Django.

So, let's bring it all together:

What you're proposing -- view predicates -- isn't going to happen.
You're welcome to keep tilting at this windmill, but the chances of
this making it into Django proper are essentially nil. However, if
you're willing to take a step back from your specific problem, there
*is* something worth looking at here: making routing, in general,
something that's easier to swap out. So the path forward for you, if
you're willing to rise to the challenge, involves figuring out how to
make routing more flexible to the point that what you want to
implement is doable as a trivial third-party package.

Jacob

On Wed, May 22, 2013 at 6:13 PM, Rach Belaid  wrote:
> 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.
> Which is more difficult with Django because routing and view lookup are the
> same thing.
>
> @Sean , I understand your point about have a single view but I hope this
> could help people to organize
> their function based views in a nice way in the same way that required_GET
> could be done inside the view.
>
> Will be great if you take few min to look how this feature is used in other
> framework.
>
> I'm personally not convince my implementation is the right one but I hope
> that could open the discussion
> to have a more extensible routing in Django.
>
> On Wedn

Re: selecting app for syncdb

[Russell Keith-Magee]

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 this incomplete state, you'll get unpredictable behaviour from
any join on this foreign key. Then, when you *do* run the syncdb on the
second application, you need to be able to identify which foreign key
columns have been correctly constrained.

While it may be *possible* to resolve these issues, it's must easier to
just synchronise everything.

Is there a particular reason that you want a per-app syncdb? I'm having
difficulty thinking of a use case where this would be beneficial.

Yours,
Russ Magee %-)

On Thu, May 23, 2013 at 3:50 AM, Michał Nowotka  wrote:

> 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 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: Proposal: Support for HTTP PATCH method

[Russell Keith-Magee]

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 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 test client is already done):
>
> https://code.djangoproject.**com/ticket/20478
> https://github.com/django/**django/pull/1198
>
> I agree that leaving the rest of PUT/PATCH issues untouched for now looks
> like a reasonable approach.
>
> --
> Krzysiek
>
> --
> 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+unsubscribe@**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: Passing parameters to raw()

[Russell Keith-Magee]

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 * FROM myapp_person WHERE last_name = %s',
> [lname])
>
> params is a list of parameters. You’ll use %s placeholders in the
> query string (regardless of your database engine); they’ll be replaced
> with parameters from the params list.
> """
>
> 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)
>
> however still this fails:
>
> >>> repr(qs)
> /home/user/vpy/dev/lib/python2.7/site-packages/django/db/models/query.pyc
> in __repr__(self)
>1530
>1531 def __repr__(self):
> -> 1532 return "" % (self.raw_query %
> tuple(self.params))
>1533
>1534 def __getitem__(self, k):
>
> TypeError: format requires a mapping
>
> If no one objects, I could write a patch to the code and the docs that
> implements the functionality.
>
> Hi Roman,

Sounds reasonable to me. Off the top of my head, I'm not certain how many
of the database backends support the pyformat paramstyle, but given that at
least some of them do, I can't see why the __repr__ of .raw() shouldn't
support it.

Yours,
Russ Magee %-)

-- 
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: selecting app for syncdb

[Shai Berger]

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 off Andrew for a minute... :)

-- 
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: implement Postgres CLUSTER USING by default for MtM tables

[Donald Stufft]

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



What do you mean by "clustering by default". CLUSTER is a one time operation. 
You use to to arrange the orders of the row in a table but after they have been 
arranged it has no long lasting affects past that.

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



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Russell Keith-Magee]

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 cluster command at the
database level. Given that this is a very low level optimisation, is there
any reason that this needs to be exposed as a Django-level API optimisation
option?

Yours,
Russ Magee %-)

On Wed, May 22, 2013 at 9:28 AM,  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
> ++--
>   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.
>
>
>

-- 
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: Predicate as suggested new feature to extend url resolver process

[Rach Belaid]

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. 
Which is more difficult with Django because routing and view lookup are the 
same thing.

@Sean , I understand your point about have a single view but I hope this 
could help people to organize 
their function based views in a nice way in the same way that required_GET 
could be done inside the view.

Will be great if you take few min to look how this feature is used in other 
framework.

I'm personally not convince my implementation is the right one but I hope 
that could open the discussion
to have a more extensible routing in Django. 

On Wednesday, 22 May 2013 23:21:33 UTC+1, sebleier wrote:
>
> 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 have negative 
> implications, especially for performance.  On top of that, the same 
> functionality could be achieved by creating a function/class to route 
> the request further after django has initially routed the request. 
> This would be preferable because the performance hit would be isolated 
> to the resolved routing function/class. 
>
>
>
> On Wed, May 22, 2013 at 2:37 PM, Jacob Kaplan-Moss 
> > 
> wrote: 
> > 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 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 feature in Pyramid/Pylons to allow more complex and flexible 
> >> routing. 
> >> 
> >> I will be curious about feebacks? Do you like this idea of features ? 
> >> 
> >> The implementation is probably imperfect so don't be too harsh ;) we 
> >> can always fix the implementation. 
> >> 
> >> For people unaware about what is a predicate, I advice to check the 
> >> pyramid doc here: 
> >> 
> http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/viewconfig.html#predicate-arguments
>  
> >> 
> >> -- 
> >> 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. 
> > 
> > 
>

-- 
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: Passing parameters to raw()

[Shai Berger]

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 currently works almost by chance -- it depends on the database access 
library's support for 'pyformat' parameter style; support which, luckily, is 
there in most supported databases. The Oracle backend, specifically, does not 
currently support this; see ticket #10070[0]. Also, there was very recently a 
related discussion on this list[1].

> however still this fails:
> >>> repr(qs)
> 
> /home/user/vpy/dev/lib/python2.7/site-packages/django/db/models/query.pyc
> in __repr__(self)
>1530
>1531 def __repr__(self):
> -> 1532 return "" % (self.raw_query %
> tuple(self.params))
>1533
>1534 def __getitem__(self, k):
> 
> TypeError: format requires a mapping
> 
> If no one objects, I could write a patch to the code and the docs that
> implements the functionality.
> 
It would be nice if you could add this note to ticket #10070 -- I don't 
believe the current patches against it address it.

Thanks,
Shai.

[0] https://code.djangoproject.com/ticket/10070
[1] https://groups.google.com/d/topic/django-developers/c1t3zwKMMmk/discussion

-- 
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: selecting app for syncdb

[Łukasz Langa]

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: 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: selecting app for syncdb

[Shai Berger]

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 some problems with the latest released version 
(0.7.6), which are already solved in the development version, and there is of 
course the Oracle limitation of no-transactional-DDL; we picked an unreleased 
version, and we use it in production with no special issues, in a project with 
hundreds of migrations.

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: Predicate as suggested new feature to extend url resolver process

[Sean Bleier]

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 have negative
implications, especially for performance.  On top of that, the same
functionality could be achieved by creating a function/class to route
the request further after django has initially routed the request.
This would be preferable because the performance hit would be isolated
to the resolved routing function/class.



On Wed, May 22, 2013 at 2:37 PM, Jacob Kaplan-Moss  wrote:
> 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 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 feature in Pyramid/Pylons to allow more complex and flexible
>> routing.
>>
>> I will be curious about feebacks? Do you like this idea of features ?
>>
>> The implementation is probably imperfect so don't be too harsh ;) we
>> can always fix the implementation.
>>
>> For people unaware about what is a predicate, I advice to check the
>> pyramid doc here:
>> http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/viewconfig.html#predicate-arguments
>>
>> --
>> 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.
>
>

-- 
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: Predicate as suggested new feature to extend url resolver process

[Rach Belaid]

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

Better example:

You post two forms on the same url.

:: urls.py ::

urlpattern += ( url('^$',view_signin), url('^$',view_signup))

signin = lambda r : 'signin' in r.POST
signup = lambda r : 'signup' in r.POST

:: views.py ::

@url_predicates([signin,])
def view_signin(request):
   

@url_predicates([signup,])
def view_signup(request):
   

No matter of the order of the urls regexp in the urls.py the right
view will match.

I can imagine that view predicate can look a bit obscure with having
used them in an other frameworks.

I did some slides which cover this feature in Pyramid.. It should make
the things more clear
http://www.slideshare.net/rachbelaid/pyramid-views-20820325


On May 22, 10:37 pm, Jacob Kaplan-Moss  wrote:
> 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 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 feature in Pyramid/Pylons to allow more complex and flexible
> > routing.
>
> > I will be curious about feebacks? Do you like this idea of features ?
>
> > The implementation is probably imperfect so don't be too harsh ;) we
> > can always fix the implementation.
>
> > For people unaware about what is a predicate, I advice to check the
> > pyramid doc here:
> >http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/viewcon...
>
> > --
> > 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 athttp://groups.google.com/group/django-developers?hl=en.
> > For more options, visithttps://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: Predicate as suggested new feature to extend url resolver process

[Jacob Kaplan-Moss]

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 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 feature in Pyramid/Pylons to allow more complex and flexible
> routing.
>
> I will be curious about feebacks? Do you like this idea of features ?
>
> The implementation is probably imperfect so don't be too harsh ;) we
> can always fix the implementation.
>
> For people unaware about what is a predicate, I advice to check the
> pyramid doc here:
> http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/viewconfig.html#predicate-arguments
>
> --
> 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: selecting app for syncdb

[Michał Nowotka]

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 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: selecting app for syncdb

[Aaron C. de Bruyn]

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

selecting app for syncdb

[Michał Nowotka]

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

Predicate as suggested new feature to extend url resolver process

[Rach Belaid]

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 feature in Pyramid/Pylons to allow more complex and flexible
routing.

I will be curious about feebacks? Do you like this idea of features ?

The implementation is probably imperfect so don't be too harsh ;) we
can always fix the implementation.

For people unaware about what is a predicate, I advice to check the
pyramid doc here:
http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/viewconfig.html#predicate-arguments

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

[Krzysztof Jurewicz]

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 test client is already done):


https://code.djangoproject.com/ticket/20478
https://github.com/django/django/pull/1198

I agree that leaving the rest of PUT/PATCH issues untouched for now 
looks like a reasonable approach.

--
Krzysiek

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

Passing parameters to raw()

[Roman Klesel]

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 %s placeholders in the
query string (regardless of your database engine); they’ll be replaced
with parameters from the params list.
"""

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)

however still this fails:

>>> repr(qs)
/home/user/vpy/dev/lib/python2.7/site-packages/django/db/models/query.pyc
in __repr__(self)
   1530
   1531 def __repr__(self):
-> 1532 return "" % (self.raw_query %
tuple(self.params))
   1533
   1534 def __getitem__(self, k):

TypeError: format requires a mapping

If no one objects, I could write a patch to the code and the docs that
implements the functionality.

Regards Roman

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