Late reply I know but I see a lot of FUD in this thread and I want to try
and clear it up.
> in the general case, STI means you have to make almost all the fields in
your model NULLable. You lose any semblance of having an actual database
schema, and end up writing a whole lot of code to re-im
> That would be a good way to address it, I think. We are calling prepare()
for order_by already. We could add a parameter prepare(...,
allow_ordering=False) and throw an exception for non-default ordering
unless allow_ordering was set to True.
I'd prefer not to include an extra argument to pre
> Anything utility functions included in core need a way for 3rd party
backends to flag as not supported or be able to tweak the underlying SQL.
The most likely tweak would be renaming the function to match the specifics
of the database. I have to do this for some of the aggregation functions,
I used the patch in the above ticket as a base, and implemented fixture
loading in the setUpClass classmethod rather than the setUp method. I found
that it improved the total running time of the entire test suite by about
10%, but it improved TestCases that use fixtures by a factor of 3.
https:
On Tuesday, 10 June 2014 00:48:14 UTC+1, Josh Smeaton wrote:
>
> > However, I think having some special case code in filter(), annotate()
> and anything else that takes expressions would be OK
>
> I strongly disagree with this. Expressions are context insensitive at the
> moment, which means they
On Mon, Jun 9, 2014 at 7:48 PM, Josh Smeaton wrote:
> - should expressions in order_by support random ordering (?) ? I don't
> think so, but I haven't ever had a need for random ordering so I'm not sure.
>
It should be possible to create an expression for order_by that essentially
does this, at
Thanks Chris. Yes, I do share your feeling that the declare-a-global-var
way of doing things is bit icky. My reason for wanting to support it was
that in order to use the "proper" method you need to be able to parse JSON
and that means that if you want to support older browsers you've now got a
dep
I don't have strong opinions on either of the contentious issues in this
discussion, but I do want to weigh-in and say that I think this is an
important and exciting feature.
On Mon, Jun 9, 2014 at 7:48 PM, Josh Smeaton wrote:
> > However, I think having some special case code in filter(), anno
