Using python for a CAD program

baalbek rcs at
Sun May 21 22:29:19 CEST 2006

David Cuthbert wrote:
> Some kind of transactionality is needed for undo/redo, but this is 
> usually done in a different (some might say "more efficient", others 
> might say "hackier") method than how transactions are implemented for 
> RDBMS (that I've dealt with, anyway).  I suspect this can be attributed 
> to two major factors: concurrent access is never an issue in such 
> systems, and the number of database objects representing a given state 
> is far larger than in, say, e-commerce.

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.

And as far as administering the dwgs (see to it that the mass of 
drawings follow one dimensioning convention, similar fonts etc) the CAD 
systems today are a pure joke: roughly 10-30% of the time the architects
spend on CAD is pure "hacking" each drawing to conform to standard, 
problems with layers being out of sync with the rest, internal blocks 
not being uptodate, etc etc etc.

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

This is in 2006, not 1986!

All of these problems (the technical ones, as well as problems of 
concurrency) would be neatly solved if the data had been stored in a 
RDBMS, instead being spread around on thousands of files on disk.

The Autocad DWG format is already in a database like structure (tables 
being joined by keys etc), so the technical difficulty is not the 
show-stopper here; I suspect the management at Autodesk will simply not 
touch the milk-cow that Autocad has become, and does not understand the 
needs of the average CAD user anyway...

I'm myself really fed up with the CAD situation of today, having battled 
for 10 years the various problems that comes with todays stone-age CAD 
systems. Jeez, 2006, and the state of the art CAD, Autocad, is still 
basically a primitive, one-user binary application. What a pathetic joke!


More information about the Python-list mailing list