Hi Craig,

I have updated jdo.dtd as you proposed and then changed jdo.xsd, orm.dtd
and orm.xsd accordingly. I figured out that jdo.dtd and orm.dtd define
the subelements for the element key in a different order. I fixed this
and change orm.dtdt to match the order as defined in jdo.dtd.

Please have a look at the attached patch. It includes the changes of
jdo.dtd, jdo.xsd, orm.dtd and orm.xsd. I would like to check them in
first, before checking in the schema validation test for api20.

Regards Michael
[vbcol=seagreen]
> Hi Michael,
>
> On Feb 19, 2006, at 12:31 PM, Michael Bouschen wrote:
> 
>
>
> I think this should allow any number of extensions before or after,
> and your choice of one of column*, field*, or property*. I don't
> think it makes sense for a foreign key, index, or unique to combine
> more than one.
>
> I thought that (column* | field* | property*) said that.
>
> So, my proposal:
>
> <!ELEMENT foreign-key (extension*, (column*| field*| property*),
> extension*)>
>
> 
>
>
> I found some information on this:
> InnoDB rejects any INSERT or UPDATE operation that attempts to create
> a foreign key value in a child table if there is no a matching
> candidate key value in the parent table. The action InnoDB takes for
> any UPDATE or DELETE operation that attempts to update or delete a
> candidate key value in the parent table that has some matching rows
> in the child table is dependent on the referential action specified
> using ON UPDATE and ON DELETE subclauses of the FOREIGN KEY clause.
> When the user attempts to delete or update a row from a parent table,
> and there are one or more matching rows in the child table, InnoDB
> supports five options regarding the action to be taken:
>
> CASCADE: Delete or update the row from the parent table and
> automatically delete or update the matching rows in the child table.
> Both ON DELETE CASCADE and ON UPDATE CASCADE are supported. Between
> two tables, you should not define several ON UPDATE CASCADE clauses
> that act on the same column in the parent table or in the child table.
> SET NULL: Delete or update the row from the parent table and set the
> foreign key column or columns in the child table to NULL. This is
> valid only if the foreign key columns do not have the NOT NULL
> qualifier specified. Both ON DELETE SET NULL and ON UPDATE SET NULL
> clauses are supported.
> NO ACTION: In standard SQL, NO ACTION means no action in the sense
> that an attempt to delete or update a primary key value is not
> allowed to proceed if there is a related foreign key value in the
> referenced table. InnoDB rejects the delete or update operation for
> the parent table.
> RESTRICT: Rejects the delete or update operation for the parent
> table. NO ACTION and RESTRICT are the same as omitting the ON DELETE
> or ON UPDATE clause. (Some database systems have deferred checks, and
> NO ACTION is a deferred check. In MySQL, foreign key constraints are
> checked immediately, so NO ACTION and RESTRICT are the same.)
> SET DEFAULT: This action is recognized by the parser, but InnoDB
> rejects table definitions containing ON DELETE SET DEFAULT or ON
> UPDATE SET DEFAULT clauses.
>
> So I think that the delete-action should allow all of the cascade,
> null, none, restrict, and default. None might be "deferred checking"
> but otherwise is the same as restrict.
> 
>
>
> I think both delete-action and update-action should allow all of the
> actions.
> 
>
>
> Ok.
>
> Craig
> 
[...]

--
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66
Fax.:++49/30/2175 2012		D-10783 Berlin

Attachment: xsd-dtd-changes-060220.patch
This has been downloaded 0 time(s).

[ Post a follow-up to this message ]