Re: Using EXISTS instead of IN for subqueries

2013-03-26 Thread Michael Manfre
On Tue, Mar 26, 2013 at 5:47 PM, Petite Abeille wrote: > > On Mar 26, 2013, at 10:03 PM, Alex Gaynor wrote: > > > For what it's worth, SQL2011 does define OFFSET, finally. > Just checked and it appears this has been implemented with SQL Server

Re: Proposal for allowing dynamic site based on domain name WITHOUT changing settings.SITE_ID.

2013-03-26 Thread meric
I've just read the previous discussion and I now have the same conclusion as yours - the optional request argument doesn't provide much the user can't do easily anyway. They can always make a custom function to grab the site based on the request. The value of Site.objects.get_current() as you

Re: Using EXISTS instead of IN for subqueries

2013-03-26 Thread Petite Abeille
On Mar 26, 2013, at 10:03 PM, Alex Gaynor wrote: > For what it's worth, SQL2011 does define OFFSET, finally. Perhaps worthwhile mentioning as well : "Do not try to implement a scrolling window using LIMIT and OFFSET. Doing so will become sluggish as the user scrolls

Re: Using EXISTS instead of IN for subqueries

2013-03-26 Thread Alex Gaynor
For what it's worth, SQL2011 does define OFFSET, finally. Alex On Tue, Mar 26, 2013 at 5:00 PM, Petite Abeille wrote: > > On Mar 26, 2013, at 4:19 PM, Michael Manfre wrote: > > > Maybe someday the non-standard LIMIT/OFFSET keywords will get added

Re: Proposal for allowing dynamic site based on domain name WITHOUT changing settings.SITE_ID.

2013-03-26 Thread Carl Meyer
On 03/25/2013 09:25 PM, meric wrote: > Previous discussion: > https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/dynamic$20sites/django-developers/QSXLGSxy7Vk/TxgiJzz5nd8J > https://code.djangoproject.com/ticket/16983 > https://code.djangoproject.com/ticket/4438 If you're

Re: Using EXISTS instead of IN for subqueries

2013-03-26 Thread Tim Chase
On 2013-03-26 15:54, Michael Manfre wrote: > On Tue, Mar 26, 2013 at 12:40 PM, Anssi Kääriäinen > deal with limit/offset. A generic approach would be nice to have, > but I can't imagine a generic way that would let me generate the > "SELECT ... FROM (SELECT ROW_NUMBER() OVER (...)) WHERE ..." >

Re: URL dispatcher fallthrough?

2013-03-26 Thread Val Neekman
+1 here! It might also be a great feature to run the 404 through before sending that email out. A replacement and/or complement to IGNORABLE_404_URLS Val On Tue, Mar 26, 2013 at 1:25 PM, Loic Bistuer wrote: > +1 for me. > > Having a catchall view under a single URL

Re: URL dispatcher fallthrough?

2013-03-26 Thread Loic Bistuer
+1 for me. Having a catchall view under a single URL pattern is a tightly coupled system, more so than allowing independent views to "test the water". Django core relies on middleware hacks because the URL dispatcher is missing this very feature. Having this in core would allow a cleaner

Re: Using EXISTS instead of IN for subqueries

2013-03-26 Thread Anssi Kääriäinen
On Tuesday, March 26, 2013 5:19:52 PM UTC+2, Michael Manfre wrote: > > > > On Tue, Mar 26, 2013 at 10:23 AM, Tim Chase > > wrote: > >> EXISTS also has some nice features >> like the ability to do testing against multiple columns, i.e., you >> can't do something

Re: Using EXISTS instead of IN for subqueries

2013-03-26 Thread Michael Manfre
On Tue, Mar 26, 2013 at 10:23 AM, Tim Chase wrote: > > In SQL 2008r2, the optimizer is usually smart enough to end up with > > the same execution plan for IN and EXISTS queries. Historically, > > EXISTS was usually the faster operation for SQL Server and if > >

Re: Using EXISTS instead of IN for subqueries

2013-03-26 Thread Tim Chase
On 2013-03-25 22:16, Michael Manfre wrote: > On Monday, March 25, 2013 6:58:12 AM UTC-4, Tim Chase wrote: > > I can only speak for testing IN-vs-EXISTS speed on MSSQLServer at > > $OLD_JOB, but there it's usually about the same, occasionally > > with IN winning out. > > In SQL 2008r2, the

Re: URL dispatcher fallthrough?

2013-03-26 Thread Andre Terra
On Tue, Mar 26, 2013 at 10:44 AM, meric wrote: > Thinking through Adrian's post and mine above, it appears to be a trade > off between coupling in the framework and increased responsibility for user > views code. Personally I would opt for the former, because IMHO the idea of

Re: What can I do to get feedback on my pull request?

2013-03-26 Thread Jacob Kaplan-Moss
Adrian's one of the BDFLs (I'm the other), so if he says "no" that stands. Usually, we operate the way most open source projects do: "rough consensus and working code". You've got the second ("working code") so you need to work on the first, I think. Usually a strong consensus is enough to

Re: What can I do to get feedback on my pull request?

2013-03-26 Thread meric
Is the 'vote' a majority or a consensus must be achieved? -- 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.

Re: What can I do to get feedback on my pull request?

2013-03-26 Thread Jacob Kaplan-Moss
On Mon, Mar 25, 2013 at 10:50 PM, meric wrote: > What action, if any, do you suggest I take now? If it's gonna get in, you/we need to talk Adrian into dropping his -1 vote. Jacob -- You received this message because you are subscribed to the Google Groups "Django

Re: Using EXISTS instead of IN for subqueries

2013-03-26 Thread Anssi Kääriäinen
On 26 maalis, 07:16, Michael Manfre wrote: > On Monday, March 25, 2013 6:58:12 AM UTC-4, Tim Chase wrote: > > > I can only speak for testing IN-vs-EXISTS speed on MSSQLServer at > > $OLD_JOB, but there it's usually about the same, occasionally with IN > > winning out. > > In