Maintaining referential integrity using MS SQL server

Question

Some time ago I posted a question relating to the following extension:
<extension vendor-name="kodo" key="jdbc-delete-action" value="null"/>
Kodo generates a "on delete set null" constraint for this, however ms sql
server does not support this. Since I don't want to matain this referential
integrity in my java code (meaning as soon as an object is deleted, setting
all references to it to null), I tried to implement a custom dictionary with
the default ms sql server solution for this problem: creating a trigger by
overriding the "getAddForeignKeySQL" method. This works fine when creating a
database from scratch using the schema tool, however, when updating an
existing databasebase schema, this is ignored, thereby not solving the
problem of having the database maintenance automated. I suppose I have to
write code for checking whether the trigger already exists. Browsing through
the code, I couldn't figure out how this is done. Can someone give me
suggestions on how to do this (and if this takes a lot of effort).
I also would like to know whether solarmetric has intentions to deal with
this problem in their framework. To be honest, I was quite surprised that
Kodo doesnt take care of this, leaving my database in an inconsistent state.
kind regards,
Christiaan

Answer 1

"Abe White" <[email protected]> schreef in bericht
news:caaunu$ecj$[email protected]..
>
I also would like to know whether solarmetric has intentions to dealwith
this problem in their framework. To be honest, I was quite surprisedthat
Kodo doesnt take care of this, leaving my database in an inconsistentstate.
>
Well, I would say that you're the one leaving the database in an
inconsistent state by not keeping your object model consistent :)From the manual:
6.2.2.12. jdbc-delete-action
If a field holds a relation to another object, you can use the
jdbc-delete-action field extension to control the delete action of the
database foreign key that models this relation. Possible values are:
null: Null the column(s) of this foreign key when the related record is
deleted.
It does mean that if the primary key record is deleted, all foreign keys to
the record are set to null, right? Since the jdo framework is about database
independence, not writing sql code (and of course lots more;) and Kodo
supports ms sql server, I would have expected that kodo to set the foreign
key to null if the object is deleted. Even if I do know sql server supports
does not support a 'on delete set null' sql statement;)
>
We have no plans to create triggers at this time.
What do you mean when you say "it is ignored" when you're updating?
Exactly what tool are you running, what actions are you running with, is
the foreign key extension present, and what is the outcome?Like I said, I wrote code in the "getAddForeignKeySQL" in the dictionary, so
a trigger is created when creating the database in the workbench (by running
the schematool). However, if the table already exists, but not the trigger,
refreshing the database from the workbench does not call the
getAddForeignKeySql to add the trigger to the table.