On 8/29/07, Marijn Haverbeke marijnh@gmail.com wrote:
Hey Ryszard,
Great work! I've only checked it out globally, but it looks very nice.
Thanks!
I'm always a big fan of keeping stuff separate, rather than integrating things into big blobs of code, so I'm glad you managed to make this a separate library. Have you found a way around the issues postgres has with creation and deletion of tables that have foreign keys referring to each other? (i.e. it will not let you put your database in an incorrect state)
Not really. I also have a problem if a class refers to a not-yet-existing class/table in its foreign key: Postgres will stubbornly refuse to create it.
At the moment I am working on a workaround for it. I want to separate the foreign key stuff from the table creation, i.e. I want to first create the table, and then add constraints to it (this would also allow me to check if the constraints are right when the table already exists). I plan to put the code for setting foreign key constraints into a lambda, and wrap its funcall by handler-case. If everything goes right, this is the end of the story for that lambda. If the handler-case catches a PostgreSQL error, then the lambda is stored somewhere. Then, when a class of db-class is created, it tries to run all the canned constraints available.
There are two things about this approach I am not so happy about. First, this means adding an additional attribute to DB-CLASS-SLOT-DEFINITION. Secondly, I am not really sure what is the best way of dealing with classes that have delayed constraints that hadn't been fired (like when, for example, the user had forgotten to write the definition of the class referred to).
Do you feel this approach is sensible? Or maybe anybody has a better idea?
Bests,
-- Richard