[postmodern-devel] Submarine announcement

[Ryszard Szopa]

On 8/29/07, Marijn Haverbeke <marijnh at 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

-- 
http://szopa.tasak.gda.pl/