Using python for a CAD program

[David Cuthbert]

baalbek wrote:
> No, concurrent access is highly relevant; for example, on a team of 
> about 50 architects working on design and production drawings for a new 
> hospital, each floor was one 'drawing' (dwg file), and thus stored on 
> disk as a separate entity from the other floors.
> 
> Now, only one architect could work on one floor at any time! And as info 
> from the project goes (sums and statistics of data, for example areas), 
> the only reliable (an efficient) way to gather this was to hack an 
> in-house application that collected the desired info from the various 
> binary dwgs stored on disk, and saved this data this to a RDBMS, for 
> further report processing.

You have two orthogonal thoughts going here.

It makes sense to collect statistics from a given drawing into an RDBMS 
in such a way that, whenever a design is checked in, the statistics are 
synched with the RDBMS.  Further, such a system could (and should) make 
sure that no previous checkin has been clobbered.  This is a classic 
source control system.  I'd be surprised if there aren't plenty of 
add-ons which do this.  At Cadence, we provided hooks for such systems 
to automatically collect necessary information.

This does not mean the design itself should be stored as an RDBMS.  As 
I've stated previously, CAD data (both electrical and, it appears, 
mechanical) does not lend itself to RDBMS relationship modeling.

What you want is an easy way to manage the information, not dictate the 
storage format of the information.

> And just to work on one small area of a huge floor, the architect has to 
> load the whole freaking floor...

I don't have any architectural experience, so I can't say whether this 
makes sense or not.  However, I think of this as being akin to 
complaining, "Just to edit a single function, I have to load the entire 
source file/check out the entire module/rebuild and rerun all the tests!"

Not that this is necessarily an invalid idea.  However, my experience 
with Cadence's tools makes me believe the existing behavior might just 
be the lesser of two evils.  CDBA has a strict library/cell/view 
hierarchy; the checkout granularity here is (usually) at the view level 
(that is, when you lock a design, you're locking the view).  Two 
designers could edit two different cells or views in the same library. 
This leads to all kinds of data inconsistency problems -- cell borders 
aren't lining up in a layout, for example, or the cached data isn't 
valid, etc.  It's a nightmare.

The newer OpenAccess system has an option to manage this at the library 
level.  Unfortunately, this is rarely enabled due to backwards 
compatibility.