Hi,
The following is a reverse engineered database View:
CREATE VIEW AT_FIXED_BLOCK_MAP_V
AS
SELECT
ATFBLO_ID,
BRANCH_ID,
(SELECT TRACK FROM AT_BRANCH_TRACK ABT WHERE ABT.ATBTRA_ID = M.BRANCH_ID),
MIN_ABSCISSA,
MAX_ABSCISSA,
GENERIC_ID,
ZONE_TYPE,
(SELECT NAME FROM ZONETYPE WHERE PKEY = M.ZONE_TYPE),
CREATED_BY,
DATE_CREATED,
MODIFIED_BY,
DATE_MODIFIED
FROM
AT_FIXED_BLOCK_MAP M
ORDER BY
ZONE_TYPE,
BRANCH_ID,
MIN_ABSCISSA
;
If we Generate DDL, this is exactly what we get...
However, the rendering of the view on the diagram is a bit sparse. So we thought we'd add some attributes that represent the returned columns...
When we do that, the Generate DDL function generates:
CREATE TABLE AT_FIXED_BLOCK_MAP_V (
ATFBLO_ID
)
;
CREATE VIEW AT_FIXED_BLOCK_MAP_V
AS
SELECT
ATFBLO_ID,
BRANCH_ID,
(SELECT TRACK FROM AT_BRANCH_TRACK ABT WHERE ABT.ATBTRA_ID = M.BRANCH_ID),
MIN_ABSCISSA,
MAX_ABSCISSA,
GENERIC_ID,
ZONE_TYPE,
(SELECT NAME FROM ZONETYPE WHERE PKEY = M.ZONE_TYPE),
CREATED_BY,
DATE_CREATED,
MODIFIED_BY,
DATE_MODIFIED
FROM
AT_FIXED_BLOCK_MAP M
ORDER BY
ZONE_TYPE,
BRANCH_ID,
MIN_ABSCISSA
;
(If we add one attribute - ATFBLO_ID)
In other words, the View suddenly becomes a Table as well!
This is inconsistent! Especially as the element type of the View is Class (perhaps it should be Table - but it isn't!)
Since the View support is embryonic, perhaps it could ignore any features applied to the Element?
Also, the «VIEW» stereotype is UPPERCASE when none of the other stereotypes are...
OK, so we delete the attribute and (re)Generate DDL... Now we get back what we started with.
(In passing, because of the current (flawed) generation process - any comments on the View are placed before the CREATE statement - which won't work in practice!)
Help?
Paolo
