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 SQL 2008r2, the optimi
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 developers" group.
To unsubsc
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.
T
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 overrid
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 a
framework is to reduce responsibility of user code and promoting same
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
> a framework is to
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 optimi
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
> > memory serves it had to deal with it
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 like
>>
>> select *
>> from
+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 implem
+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 pattern is a tightly coupled
It works! Thanks a lot!
On Tue, Mar 26, 2013 at 12:45 AM, Claude Paroz wrote:
> Le samedi 23 mars 2013 22:28:31 UTC+1, Claude Paroz a écrit :
>>
>> Le samedi 23 mars 2013 12:16:15 UTC+1, Evgeny a écrit :
>>>
>>> Hi.
>>>
>>> Is it necessary to cast help_text to string in Field.__init__ there
>>> h
On Tue, Mar 26, 2013 at 12:40 PM, Anssi Kääriäinen
wrote:
> Hmmh, this means Oracle, MSSQL, DB2 and Informix are doing more or less
> the same thing for limit/offset support? If so, then having a more generic
> approach to this problem than having a custom compiler per backend might be
> worth it.
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 ..."
> mon
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 in
On Mar 26, 2013, at 4:19 PM, Michael Manfre wrote:
> Maybe someday the non-standard LIMIT/OFFSET keywords will get added to the
> standard (I truly hope this happens) so Oracle, MSSQL, DB2, and Informix
> could share SQL with postgres and mysql without needing to mangle it.
FWIW, Oracle 12c is
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 to
> the
> > standard (I truly hope this happen
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 down toward the bottom of
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 p
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 2012.
A quick check of the other database with Djang
20 matches
Mail list logo
