Loading ...
Sorry, an error occurred while loading the content.


Expand Messages
  • robin@fried.net
    Feb 27, 2001
      I think Ron's idea of a specification/requirements for UPDATE/DELETE
      is the only way to go before writing code. That way people have an
      opportunity to see whether or not the design meets their requirements
      before waiting to be disappointed.

      Has a list of requirements/designs been produced (other than Ron's
      below for delete)?


      --- In xml-dbms@y..., Ronald Bourret <rpbourret@r...> wrote:
      > Sorry to take so long replying.
      > Before you write any code, I strongly suggest that you write a short
      > specification of how update and delete will function and post it to
      > list for feedback. That will probably save a lot of time later.
      > My current suggestions for DELETE are as follows. If people think
      > is a good solution (FEEDBACK PLEASE!), you might want to write this
      > while we think about how to do UPDATE, which is much harder.
      > I'll try to send ideas about update by Friday.
      > -- Ron
      > DELETE
      > ------
      > This can be implemented similarly to DBMSToDOM. That is, the basic
      > is that the code traverses the database hierarchy and, instead of
      > building a DOM document, deletes rows.
      > The only tricky part of this is that rows must be deleted in the
      > required by referential integrity. That is, all foreign key rows
      must be
      > deleted before any primary key rows. The algorithm for this is
      > as follows:
      > 1) Get the TableMap for a given table.
      > 2) Check all relatedTables. If parentKeyIsCandidate is true for a
      > table, then process the relatedTable immediately. (That is,
      > start with step 1 for the relatedTable.) This will delete all rows
      > child tables for which the current table has the primary key and the
      > child rows have the foreign key.
      > 3) Delete the row in the current table.
      > 4) Check all relatedTables again. This time, if
      parentKeyIsCandidate is
      > false, process the relatedTable. (That is, recursively start with
      step 1
      > for the relatedTable.) This will delete all rows in child tables for
      > which the current table has the foreign key and the child rows have
      > primary key.
      > Here is a proposed API. Comments welcome. Note that the Map object
      > now passed as an argument to each method, rather than being set
      ahead of
      > time. This is a change I am considering making on DBMSToDOM and
      > DOMToDBMS as well, as it simplifies the interface and makes clearer
      > is happening.
      > public class DBMSDelete
      > {
      > /** Construct a new DBMSToDOM object. */
      > public DBMSDelete()
      > {
      > }
      > //
      > // Public methods
      > //
      > /** Delete documents from specified tables. */
      > public Document deleteDocument(Map map, String[] tableNames,
      > Object[][] keys)
      > throws InvalidMapException, SQLException
      > /** Delete a document from a specified table. */
      > public Document deleteDocument(Map map, String tableName, Object
      > key)
      > throws InvalidMapException, SQLException
      > /** Delete a document according to the information in a
      > object. */
      > public Document deleteDocument(Map map, DocumentInfo docInfo)
      > throws InvalidMapException, SQLException
      > }
      > }
      > As a starting point, you can use the DBMSDelete class from
      > www.schemantix.com. (They gave me permission to modify/use/reship
      > This is code they wrote for use with XML-DBMS that implements the
      > algorithm above, except that the version I saw did not handle
      > referential integrity -- it simply deleted rows in hierarchical
      > (If you can't find this on their site, tell me and I will send you a
      > copy. I don't know if they still use XML-DBMS.)
    • Show all 11 messages in this topic