Re: [dtp-dev] sql model validation

[rcernich@xxxxxxxxxx]

Hey Hui,

> FYI. When I use the emf EObjectValidator to validate a Derby Schema
> object, I got a lot of errors, most of which are complainting a
> reference is dangling because it's not a containment feature, but 2
> other errors might be relevant:

This is really an issue with how the models are defined.  Most
relationships are not defined as containment.  The logicalContainment
extension is responsible for identifying the containers for certain object
types within the model.  However, it should be noted that these errors are
only a concern if the model is saved.  In that event, all elements in the
model must have a container, which is where the logicalContainment
extension comes into play (we could also shove any remaining elements
without a container into the resource directly; in the event a
logicalContainment extension is not available for a particular element).


> 1. The required feature 'Catalog' of 'org.eclipse.datatools.
> connectivity.internal.derby.catalog.DerbyCatalogSchema@1d42e79{#//}'
> must be set

The Derby catalog loader has not been migrated for the recent model changes
which added support for catalogs, so it is behaving as a "legacy" catalog
loader/model would behave.


> 2. The required feature 'owner' of 'org.eclipse.datatools.
> connectivity.internal.derby.catalog.DerbyCatalogSchema@1d42e79{#//}'
> must be set

I would consider this a bug which should be logged against the Derby
connection profile/catalog loader.


> Does it mean that we should model the "catalog" feature as an
> optional one and we need to set "owner" in Derby CatalogLoader?

The relationship between Database and Schema was left in the model purely
for compatibility reasons.  Given that, I do not think the catalog feature
should be optional.  For consistency, I think a catalog object should be
incorporated into every model (JDBC accommodates this by using null or ''
for the catalog name for DB's which do not support multiple catalogs; which
we mimic in our generic JDBC catalog loader).

I'd be interested to know how the Derby model validates if you use the
generic JDBC catalog loader.  (Note, you'll need to run Derby as a
networked server and use a generic JDBC driver definition.  If you use a
Derby networked driver definition, the Derby catalog loader will be invoked
as opposed to the generic catalog loader.)

Rob