.extra() was a kludge that existed because .raw() didn't. Frankly, I'm
considering deprecating and removing .extra() entirely: I've rarely
seen a case where using it didn't come back to cause problems in the
future. I'm certainly going to be a strong -1 on adding any more
"features" to .extra().
Remember, Django's ORM tries to hit an 80-90% point, but then you're
*expected* to fall back to raw SQL past that point. Falling back to
raw SQL when it's easier is a feature, not a bug.
Jacob
Yes. Yes Yes Yes. Yes. Oh, and Yes. +1.
> I've rarely
> seen a case where using it didn't come back to cause problems in the
> future. I'm certainly going to be a strong -1 on adding any more
> "features" to .extra().
Agreed. From an engineering perspective, extra() is the single most
fragile part of the ORM. Dumping extra would make me extraordinarily
happy.
Yours,
Russ Magee %-)
Even if it is a kludge, it still accomplishes something that .raw() cannot (as Dan put forth). I think deprecating it in favor of raw doesn't make much sense, since they are two different things.