[Chicago] 2 unique keys in a python dict?

Martin Maney maney at two14.net
Fri Oct 10 02:10:17 CEST 2008


On Thu, Oct 09, 2008 at 04:16:00PM -0500, Massimo Di Pierro wrote:
> I am not suggesting using a web framework. I suggested using a DB +  
> python based database abstraction layer (I do my examples in web2py  
> because that is what I know best).
>
> Lukasz said that, in fact, he is using SQLAlchemy.

As we will see, I think either is silly overuse of complex tools for a
trivial job.  Unless the sheer size of the (unsorted) input to be
processed is huge, which I don't recall.

> Since Garrett mentioned Django (I did not) and I am not aware of how to 
> use GROUP BY in Django, the conversation sidetracked.

Oh, is that how it went?  I came across this thread after it was mostly
done, I guess, and only vaguely remember what I took to be a very
tongue in cheek mention of Django - you know, the obligatory "...or you
could use <hot thing that's got all the buzz>" mention.

> My question still stands. How would I do a GROUP BY and a SUM of the  
> grouped records in using Django without multiple queries?
>
> I would honestly like to learn that.
>
> Do you know?

I have to peel this onion in stages.

First layer: for the problem as originally stated, I'd use the CSV
library and some IMO trivial Python code (it's possible it's not quite
as simple as I imagine - from something more recent I'm not sure we've
actually got the full picture of what needs to be done in the end).

Second layer: if I were required to solve that problem using Django,
I'd import csv and proceed as above after whatever minimal Djangoness
requirement had been satisfied.

Third layer: if I had to solve the variant you seem to be asking for
above - assuming the raw records were already in a table by whatever
means - I, personally, would write a single SQL query, as this is
pretty trivial (well, after all, subtotals on a field are surely among
the common business tasks the designers of SQL had in mind).  This
exposes my bias as someone who had taken the time to learn a bit about
SQL, and more so about the relational model, years before Django came on
the scene.

Fourth layer: if you hold my feet to the fire to Do It All In Django,
No SQL Please, no problem.  Just fetch all the rows, sorted by id, and
iterate over them tossing off subtotals when the id column changes,
viz., reinvent what the simple SQL statement would be doing with much
greater data transfer requirements and reduced efficiency. (it was at
this point that the urge to override the random .sig quite became
irresistable)

There ought to be quite a bit of onion left at his point, but I'm not
sure what those layers would be.  Maybe implement the subtotal summing
in postscript and produce the report by sending the sorted data to the
print queue?  Hope it doesn't catch on fire...

-- 
This is like making a car shorter by cutting off a few inches
from each end with a Sawzall.  Of course there's little benefit,
because that's a dumb way to do it.  -- Neil R. Ormos



More information about the Chicago mailing list