Peter Clifton wrote: > > One thing I thought of whilst reading this.. is that an "attributes" > table, to store attribute meta-data which will make it into gschem. > "SELECT * FROM attributes WHERE partnum = xxxxx;" might give you the > attribute results: > > name | value > ----------+---------- > refdes | foo > value | bar > model | ...... > > etc..
Thinking further about this, we need to distinguish between definitions and instances. In my database design attribute instances are either a wider assembly table with more columns, or another table, depending on how far you with to take normalization. I would bias to an extra table: Attribute table's columns: assembly number (Note! implicitly contains revision level in my scheme) refdes attrname (Note! need to allow duplicate values!) attrvalue Revision level could be an explicit 5th column just as well. This would be quite simple to slosh back and forth between gschem and mysql. Of course, the user is faced with the issue of keeping schematic revisions in sync with what ever revision scheme is used in the database. For definitions, a new default attributes table would be needed: partnum attrname attrvalue It would be pretty easy to integrate that with a chooser. If there were a fourth column for symbol, then the symbol chooser could bet set up to either work as it does now, or to get the .sym file indirectly through the database. I can already see a hole with this... if attrnames were unique within a symbol, then multiple rows with the same attrname could imply a drop-down chooser for selecting a value from among the defaults. The chooser would get confused, however, if the same attrname wants to appear multiple times on a symbol. Need to noodle on that one. -dave _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user