[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Sjtans recent work
From: |
Horst Herb |
Subject: |
[Gnumed-devel] Sjtans recent work |
Date: |
Tue, 4 Mar 2003 15:39:48 +0000 |
User-agent: |
KMail/1.5 |
I took a few hours to go through the files in test-area/sjtan
I am highly impressed by the code - good work!
However, it wouldn't hurt to include docstrings, would make it a lot easier to
understand your thoughts, Sjan.
I) Regarding the analyse_server script:
I would propose to rather analyze table metadata directly from the backend
rather than parsing a DDL script. Unfortunately, there is no standard set
for creating tables and constraints. While most of the tables follow a fairly
consistent design, this is probably because most if not all of them have only
been written by three authors so far (me and Ian and Karsten), where
communication worked reasonably well between us.
As elegant as your regular expressions are, they are bound to fail if another
author writes DDL scripts in a different way.
Have a quick look at gmPgObject in client/python-common to see an example for
querying meta data from the backend.
If you do a "select tablename from pg_tables where tablename not like 'pg_%';"
you get a list of all tables available in that particular service;
How you get their primary and foreign keys is demonstrated in gmPgObject,
so all it takes to build up a metadata graph is cross referencing all
relationships to include the many-to-many ones (you already have all
one-to-one and one-to-many via the foreign keys directly).
Then you have all information you need to create servers programmatically
without need to parse any DDL scripts - you get the information "life" from
the backend you are going to use, knowing that you will not miss any tables.
II) Please, preferrably put a README explaining how to run your code into the
test directory as soon as you think your code can be tried out by others if
it doesn't run within the otherwise unmodified gnumed framework or is
otherwise self-explanatory (I'll have to slap my own wrists too for not doing
this consistently). As it is, I couldn't get grid_view1.py to run yet,
despite the code looking very promising
III) Please *communicate* with us. Your code is excellent, and it would be a
shame if we wouldn't use it because we don't know about it or how to use it.
IV) This is for everybody: if you have a good idea and it works for you at
home, please
- dump the database\
- pack the dump together with *all* dependent scripts into a tar file
so that we can test it in isolation without having to modify the code too much
Horst
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gnumed-devel] Sjtans recent work,
Horst Herb <=