[DB-SIG] Re: [Python-Dev] database APIs

[Kevin Jacobs]

On Wed, 5 Feb 2003, Luke Kenneth Casson Leighton wrote:
> > The table renderer makes sure that your formats match your data, so it is
> > easy to detect problems like that.  
> 
>  hmmmm :)  easy to detect problem.  hmmm.
> 
>  easier to avoid problem in first place, neh?

Avoiding the opportunity for something to be a problem sometimes removes the
opportunity to provide additional value.  Sometimes hiding necessary
complexity is the hallmark of bad (or short-sighted) design.

> > In practice, we have hundreds of reports
> > and never have a problem with keeping track of fields.  
> 
>  once written,

I've polled our various Python developers here, all of very diverse Python
guru-ness, and none seem to worry much about that.  If there was one theme
that was repeated among them was the biggest issues were change management
and formal testing methods.  The other overwhelming message is that they
much prefer writing reports in Python than in Crystal Reports, FRX, and
Cognos.

> > I'm not trying to change your mind, but our clients need all of the above
> > (and more!).
> 
>  i understand: i'm trying to get you to convince me to
>  chuck some demand-driven code where the original demands
>  weren't so demanding [as your clients]

That is the wonderful thing about Python -- incremental design is so easy. 
The only times you know you are going on the wrong direction is when your
design _never_ stabilizes or when your abstractions are not powerful enough
(like your problem of having to write too much code for each form).

>  ... i know what's bothering me.
> 
>  the number of lines of code to do reports.

So how many reports do you have?  What do they do?  And how many lines (on
average) do they take?  Here are some stats from one of our average
inventory tracking OLAP modules:

   43 source files
9,627 lines of report specific code total (not including libraries, queries, 
      and stylesheets, all of which live in other locations and are shared
      among reports)
  660 lines maximum report size
  154 lines minimum report size

Each report has, on average, 4 options that control rollups, filtering,
detail level, and formatting.  Many reports have support for multiple viewer
roles (reports look different based on the type of user viewing them). All
reports have access level filtering (not all options or data are available
for any given user).  About half compute non-trivial calculations or
projections.  Plus, each report is fairly rich in whitespace and comments. 
Lines are also kept fairly short and simple.

>  i'll send you a patch to SQLobject to do INSERT ... SELECT :)

I'm sure Ian would appreciate it.  ;)

Regards,
-Kevin


-- 
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com