I'd be glad to contribute to this, but I've a self-imposed deadline to
respect for the project I'm on and I can't spend time now to dig into
Django internals, but I stick to use existing functionality. I'm
asking a lot of questions on this group and I'm really deeply
impressed by the kindliness
On Tue, Aug 18, 2009 at 10:48 PM, mettwoch wrote:
>
> The whole thing behind that it is: I'm developing an invoicing/
> inventory application and I run into performance problems that might
> require using raw SQL and admittedly I'm not an SQL expert and I
> dislike the idea of
processing time by
> > a factor of 20 in critical areas of my application. While doing so, I
> > felt that some kind of a new field-type could be useful and perhaps
> > lead to make aggregation on expressions possible. Something like an
> > ExpressionField (or SQLFi
o reduce processing time by
> a factor of 20 in critical areas of my application. While doing so, I
> felt that some kind of a new field-type could be useful and perhaps
> lead to make aggregation on expressions possible. Something like an
> ExpressionField (or SQLField or whatever ...) that
that some kind of a new field-type could be useful and perhaps
lead to make aggregation on expressions possible. Something like an
ExpressionField (or SQLField or whatever ...) that does some SQL
processing directly on the database and that could be used like this:
class InvoiceLine():
price
5 matches
Mail list logo