Detailed Design Specification

doctorlanguidInternet and Web Development

Dec 8, 2013 (3 years and 6 months ago)

71 views


doctorlanguid_428
7da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc


Detailed Design Specification

© 200
6
, 2009

Ingres Corporation


Project Name

Renaming Tables and Columns

Author

Shubhagam Gupta

Last Saved Date


December 8, 2013



Revision


Template Revision

1.
7









doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

2

of
35


Responsibility List




Note:
The Responsibility List reflects those required to review and provide feedback
for the document.

Signoff by those listed is required prior to the beginning of the
development phase
.


Additional reviewers

Assigned To

Action

Responsibility

Signature


S
hubhagam
G
upta

Owner

Engineer/Architect


Stephen Ball

Peer Review

Development Manager


Chris Rogers

Peer Review

QA Manager



Test Review

QA Engineer


David Reed

Peer Review

Sustai
ning Engineering Manager



Sustainability
Review

Sustaining Engineering Engineer


Pam Fowler

Peer Review

Level 1 Support Manager


Bill Maimone

Peer Review

Chief Architect


Elaine Grieco

Peer Review

Technical Writer


Christine Normile

Peer Review

Produ
ct Manager



Peer Review

Services



Peer Review

Services


doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

3

of
35





Note:
The
additional reviewers list reflects other people that should be copied on the
document and invited to review meetings
,

but feedback from them is not required for
the document to be approved. Managers of other engineering gr
oups are copied for
comment on how it affects their product or product area. The manager for your own
engineering area is included in first table and can be removed from here.




SQL
Language Review

Assigned To

Action

Responsibility

Signature

Steve Ball

Information

DBMS


Teresa King

Information

Gateways


Teresa King

Information

Connectivity


Joe Kronk

Information

OpenROAD


Roger Whitcomb

Information

Tools


Emma McGrattan

Inf
ormation

Usability


doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

4

of
35





Note:
The SQL language review table l
ists people that should be sent an initial draft
copy of this document if you answered “yes” to any questions in section 2.2. If you did
not answer yes to any of those questions you may delete this table.


Assigned To

Action

Responsibility

Signature

Steve Ball

L
anguage Review

DBMS


Teresa King

Language Review

Gateways


Teresa King

Language Review

Connectivity


Joe Kronk

Language Review

OpenROAD


David Reed

Language Review

Supportability and
Backward
Compatability


doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

5

of
35


Change History:


Revision Date

Last Revision By

D
escription of

Change

30
-
Nov
-
2007

Steve Ball

Template
:
Fixed up instructions to be more Ingres
product range specific and added sections specific to
Ingres/OpenROAD

3
-
Dec
-
2007

Steve Ball

Template
:
Add tech writing
changes

and examples
section

4
-
Dec
-
2007

Steve Ball

Template
: changes based on feedback

1
-
May
-
08

Christine Normile

Template
: changes based on working meeting Punta
Cana, DR, Development Summit 2008

22
-
May
-
08

Christine Normile

Template
: removed confidential marking
s

21
-
Aug
-
2008

Steve Ball

Tem
plate
: Add language review elements

4
-
Apr
-
2009

Steve Ball

Template
:
Added section on catalog changes

08
-
Oct
-
2009

Shubhagam Gupta

Initial Version.

20
-
Oct
-
2009

Shubhagam Gupta

Updated DDS after review.


doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

6

of
35


TABLE OF CONTENTS

1

INTRODUCTION

................................
................................
................................
.............

10

1.1

S
COPE AND SUMMARY
................................
................................
................................
..........

10

1.2

D
EFINITIONS
,

A
CRONYMS AND
A
BBREVIATIONS

................................
................................
........

10

1.3

R
EFERENCES

................................
................................
................................
.......................

10

1.4

N
OTEWORTHY
I
SSUES

................................
................................
................................
...........

11

2

ARCHITECTURE OVERVIE
W

................................
................................
............................

12

2.1

HIGH LEVEL DESCRIPTI
ON

................................
................................
................................
......

12

2.2

SQL

L
ANGUAGE CHANGES
................................
................................
................................
.....

12

2.3

IMPLICATIONS FOR
GCA

................................
................................
................................
.......

15

2.4

C
ONNECTION PARAMETERS

................................
................................
................................
...

15

2.5

LANGUAGE
,

UNICODE AND INTERNAT
IONALIZATION
I
SSUES

................................
.........................

15

2.6

IMPLICATIONS FOR ING
RES
/
STAR

................................
................................
............................

16

2.7

IMPLICATIONS FOR DBA

TOOLS

................................
................................
...............................

16

2.8

NEW IMA
/
MIB OBJECTS

................................
................................
................................
.........

17

2.9

NEW TRACE POINTS

................................
................................
................................
..............

17

2.10

C
ATALOG ALTERATIONS

................................
................................
................................
.....

17

2.11

I
MPLICATION FOR
G
ATEWAYS

................................
................................
............................

17

2.12

IMPLICATIONS FOR DAT
ABASE DRIVERS

................................
................................
................

17

2.13

IMPLICATIONS FOR OPE
NROAD

................................
................................
...........................

18

2.14

D
ESIGN
L
IMITAT
IONS AND
A
SSUMPTIONS

................................
................................
............

18

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

7

of
35


2.15

P
LATFORM
S
PECIFIC
I
SSUES

................................
................................
...............................

18

2.16

P
RODUCT INTERACTION

................................
................................
................................
....

18

2.17

P
ATENT
I
NFORMATION

................................
................................
................................
.....

19

3

EXTERNAL SPECIFICATI
ON

................................
................................
.............................

20

3.1

U
SER PERSPECTIVE

................................
................................
................................
...............

20

3.2

INSTALLATION AND
A
DMINISTRATION
P
ERSPECTIVE

................................
................................
...

20

3.3

M
IGRATION
I
SSUES

................................
................................
................................
..............

20

3.4

S
ECURITY
I
MPACT

................................
................................
................................
................

21

4

INTERNAL SPECIFICATI
ON

................................
................................
..............................

22

4.1

E
STIMATED TASKS AND
E
FFORT

................................
................................
..............................

22

4.2

P
ROGRAMMING

................................
................................
................................
..................

23

4.3

C
OMPATIBILITY LIBRARY

INTERFACE CHANGES

................................
................................
...........

24

4.4

I
NTERFACE

................................
................................
................................
..........................

25

4.5

BUILD IMPLICATI
ONS

................................
................................
................................
............

25

4.6

UI

R
ESOURCE
/P
ROPERTIES
F
ILES

................................
................................
............................

25

4.7

B
ITMAP
R
ESOURCES

................................
................................
................................
.............

26

4.8

I
C
ON
F
ILES

................................
................................
................................
..........................

26

4.9

PICCOLO CHANGE NUMBE
RS

................................
................................
................................
..

26

5

IMPACT AND DOCUMENTA
TION SUMMARY

................................
................................
..

28

5.1

P
RODUCT
/C
OMPONENT
I
MPACTS

................................
................................
..........................

28

5
D
OCUMENTATION

................................
................................
................................
........................

28

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

8

of
35


6

QUALITY ISSUES

................................
................................
................................
............

30

6.1

U
NIT
T
ESTING
S
UMMARY
................................
................................
................................
......

30

6.2

HANDOFFQA IMPACT

................................
................................
................................
............

32

6.3

T
ESTING
R
ECOMMENDATIONS

................................
................................
...............................

32

6.4

R
EGRESSION
R
ISK
A
SSESSMENT

................................
................................
..............................

33

7

PACKAGING AND INSTAL
LATION IMPACT

................................
................................
.......

34

8

SUPPORT IMPACT
................................
................................
................................
..........

35

8.1

EXAMPLES AND TESTS

................................
................................
................................
...........

35


doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

9

of
35


PREFACE

This document describes external functional specifications as well as design
specifications for one
feature of a release
project. There will be many Deta
iled
Design Specifications (DDS) for each project, one for each major feature
described in the Software Requirements Specification (SRS)

or project wiki page
.
The SRS

or the wiki page

is the master document for the entire project.

This is intended to be a
living document.
The product development cycle is a
dynamic process in which our understanding of the project and its criteria for
success are refined over time. It is therefore expected that the completed
Detailed Design Specification will undergo many re
visions during the course of a
project as requirements; resources and constraints evolve.

The engineer would
not be expected to complete all sections in the initial draft; some sections are
designed so that they can only be completed one the project is cod
ed.
*note that
you are expected to continue updating this document until the
release
project is handed over to SE*

The Development Manager is responsible for the contents of this document.
Deliverables that must be completed prior to releasing this docume
nt are

at least
one of
:



Software Requirements Specification



Wiki page on the engineering web describing the components of the project


All template instructions can be identified by their
gray italic type
. This information
may be removed after completing t
he necessary project information.

Ant information detailed in this document should not be repeated in the wiki page
for this feature unless there is a compelling reason to do otherwise one of the
copies of the information may become out
-
of
-
date. If you nee
d to, refer to the DDS
on the wiki page.

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

10

of
35


1

INTRODUCTION

1.1

SCOPE

AND SUMMARY

Explain what the feature is expected to do; notes on the drivers for this feature
(such as partner or customer requirements) should be placed in here.

This document outlin
es a proposal

to enable renaming

tables and column names
in
Ingres. With this features Ingres users will be able to rename tables and column names,
using the new SQL syntax introduced.

(Refer to section 2.2 for SQL language systax).

Ingres partners like Alfresco

rename

existing tables and columns during upgrade
process. This feature will help our partners with migration to Ingres. It will also bring us
up to the par with similar capabilities offered by our competition.

1.2

DEFINITIONS, ACRONYM
S AND ABBREVIATIONS

Provide the

definitions of terms, acronyms and abbreviations required to
interpret this document. For consistency, use the format in the examples below:

Detailed Design Specification:
(DDS) A representation of a software system
or component of a system created to fac
ilitate analysis, planning,
implementation and decision
-
making. The DDS is used as the primary
medium for communicating software design information.

Click here to add additional definitions

1.3

REFERENCES



Provide a list of documents refere
nced e
lsewhere in this document and/or
other documents that were used
during research or may help the reader
understand the feature.



Identify each document by title, report number (if applicable), date and
publishing organization.



If possible, s
pecify the source
s from which the references can be obtained

Click here to begin typing
.

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

11

of
35


1.4

NOTEWORTHY ISSUES

Since the DDS is an evolving representation of the design (a "living document"),
this section is used to keep track of issues that arise during the proj
ect life cycle
and items that need special attention.

If you add a FIX_ME or comment similar
to “need to do something about blah here” to the code, you should note the
issue here.

Click here to begin typing

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

12

of
35


2

ARCHITECTURE

OVERVIEW

2.1

HIGH LEVEL DE
SCRIPTION

Describe the overall architecture. Architectural design may be represented in
many forms, including text, graphical description, pseudo
-
code representation or
combination.

Renaming of tables/column names will utilize the new alter table rename …
syntax or
the rename table syntax.

This command
will update the core catalogs to reflect the new
table /column name.

Changes will be required in scanner, parser, QEF and DMF
to support alter table alter
column and new rename syntax.


V
iew
s
, procedure
s, C
ons
traints
, and grant statements

store the referring table name in
the
query
text in iiqrytext

catalog
.

updating the

query text in
iiqrytext

catalog is out of
scope for this project.
Hence a
ny table name/ column names which are referred in
views, procedu
res,
constraints,
rules,
etc
are not allowed to be renamed. A
ppropriate
error will be given for each case.

2.2

SQL LANGUAGE CHANGES

Are there

any changes in this feature that

alter the SQL language in any way?
Did you add syntax to the Ingres SQL language? D
id you remove syntax from the
Ingres SQL language? Did you add any new data
-
types or functions to SQL? Did
you make any other changes that affect the SQL language
?

NOTE:

If you answered yes to any of the questions above you must send the
initial draft of t
he DDS for language review to the people designated in the “SQL
Language Review” table at the start of this document and fill out all of the
following sub
-
sections. If there are no
language

changes you may delete all
these sub
-
sections




doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

13

of
35


New SQL syntax t
o alter table statement is proposed for renaming tables as follows:

[EXEC SQL] ALTER TABLE [schema.]table_name RENAME TO new_table_name

R
ename operation will

fail with error if the user has any dependent objects e.g. views,
referential or check
constraints

etc.

In addition to alter table syntax above, also proposed
alternate syntax
commonly
available from other vendors

as follows:

[EXEC SQL] RENAME TABLE [schema.]table_name TO new_table_name

New SQL syntax for renaming columns is proposed as follows:

[EXEC

SQL] ALTER TABLE [schema.]table_name
RENAME [COLUMN
] col
name
1

TO new_column_name

I
f there are any dependent objects on the column colname1 for table
tabname

then
rename

operation

will fail with errors.

2.2.1

Rules and Restrictions on renaming a table name:


Ren
aming operation on a table should adhere to the following rules and restrictions.

a)

You must own the tables you are renaming.

b)

The name of the new table should conform to naming rules for tables, as outlined in the
SQL reference guide.

c)

There should be no tabl
e already existing in the database with name
same
and owned
by the same user
as
new

tab
le
name. The new

tab
le
name will get the same reltid as
the old table name.

d)

You cannot rename a system catalog, extended system catalog
, replicator catalogs
or
any tabl
es owned by super user ‘$ingres’.

e)

Renaming the table will take a Check point Lock on the database (To avoid online check
point while the rename/alter statement is executed).

The statement will take an
exclusive lock on the table being renamed.

f)

All

indexes

on the old table are automatically transferred to the newtabname.

g)

The rename or alter table rename to …operation can be rolled back.

h)

If there are any procedures, views, rules,

foreign key

constraints
or check constraints
referring to the table being ren
amed, the rename operation will fail with errors.

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

14

of
35


2.2.2

Rules and Restrictions on renaming a table column:

Renaming operation on a table column should adhere to the following rules and restrictions.

a)

You must own the table whose column you are renaming.

b)

The new c
olumn name should adhere to the naming rules for a new column name.

c)

The new column name should not already exist in the same table.

d)

You cannot rename columns of a system catalog.

e)

Columns of any tables owned by super user ‘$ingres’ cannot be renamed.

f)

If th
ere are a
ny procedures, views, rules, constraints referring to a column name
being
renamed then the
rename operation

for that column

will fail with errors.

g)

Alter table rename column operation can be rolled back.

2.2.3

Other Restrictions

2.2.3.1

ABF, QBF, REPORTS etc.

A
ny forms, join defs, reports that refer to the old ta
ble name or old column name are
invalidated. These will need to be recreated and reloaded.

2.2.3.2

COPYDB (unloaddb) scripts.

Any

unloaddb scripts

generated prio
r to renaming of table/columns cannot be used fo
r

reload
operation.

2.2.4

Language changes to Ingres/Star’

Will the language changes be implemente
d in Ingres/
star? If not why not?

No. Alter table statements are not supported in Star.

2.2.5

Language Changes

to ABF

Will the language changes be implemented in ABF? If n
ot why not?

New ALTER TABLE …RENAME syntax will be implemented for ABF parser as
well.

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

15

of
35


2.2.6

Language Changes to Database Procedures

Will the language changes be implemented or be functional inside database
procedures? If not why not?

No.

Procedures are not allo
wed to execute ALTER TABLE statements
.


2.2.7

Language Changes to Embedded SQL pre
-
compilers

Will the language changes be implemented in the embedded SQL Pre
-
compilers? If not why not?

Yes.

2.2.8

Effects on dynamic SQL

Will the language changes work in dynamic SQL?
If not why not?

Yes.

2.3

IMPLICATIONS FOR GCA

Is there anything about this feature
(including language or data
-
type changes)
that will require a new GCA message type or have any other affect on GCA?

None


2.4

CONNECTION PARAMETER
S

Does this feature require, use, o
r add any new DBMS connection parameters?

None


2.5

LANGUAGE, UNICODE AN
D INTERNATIONALIZATI
ON
ISSUES

Is there anything about this feature that causes it to have unique characteristics

or testing requirements when implemented for the international market and
support for international
or multi
-
byte
character sets

including Unicode (UTF16 or
UTF8)
?

None

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

16

of
35


2.6

IMPLICATIONS FOR ING
RES/STAR

Does this feature have any implication for Ingres/Star? If so what are they?

Star does not support Alter table (als
o by extension Re
name) statements.

If a table is registered in Star and it is renamed in the local database, any select
statements from old table name will fail with error E_US0845 table does not exist.

The old table name is recorded in the iiregistrations catalog and can
be cleaned
up using the starview utility. The new table name must be registered with the star
database using register table as link statement.

Similarly if a column of a registered table is renamed in the local database, any
select statements involving tha
t table column will fail with error E_US0834 that
the table does not contain the column specified. Please drop and re
-
register the
reg
istered table using the starview

utility to fix this problem.

Refer to chapter 6 of Star User guide for a description of t
he starview utility.

2.7

IMPLICATIONS FOR REP
LICATOR

If a table/column being renamed are registered with replicator
,

Any tables/columns registered with the replicator are
entered

in dd_regist_tables
and dd_registered_co
lumns replicator catalog.
These catalogs

need

be updated
for the replication to work.


When you

rename a registered table, carry out the rename operation on the
replicated and target databases and finally register, support a
n
d activate the new
table name

using repmgr utility.

Refer to chapter 5
of replicator user guide for a description of repmgr (replicator
manager) utility.

2.8

IMPLICATIONS FOR DBA

TOOLS

Does the feature have any implications for the DBA tools such as copydb,
auditdb, rollforwarddb, verifydb? Would a new verifydb option be useful?

Any copydb scripts that were generated previous to the rename operation should
not be used as they will
revert to the old table names.

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

17

of
35


2.9

NEW IMA/MIB OBJECTS

Did you add any IMA objects as part of this feature? Are there any that would be
useful that perhaps

you didn’t add because of lack of time?

None

2.10

NEW TRACE POINTS

Trace points should be avoided in favor of IMA objects. If you added any trace
points detail them here with an explanation of why it was not siuitable for an IMA
object.

None

2.11

CATALOG ALTERATION
S

Does the feature add or alter the Ingres catalogs, either DBMS catalogs, front
-
end catalogs, or iidbdb catalogs? If so, fill in the details here and be sure to
update the document containing the catalog spec, which can be found here:
http://community.ingres.com/wiki/Ingres_Catalogs

None

2.12

IMPLICATION FOR GATE
WAYS

Does this feature have any implications for the Ingres gateways?

Do any SQL
language changes need to be considered for implementation
in gateway
products?

None
.

2.13

IMPLICATIONS FOR DAT
ABASE DRIVERS

Does this feature have any implications for any of the database drivers such as
ODBC, JDBC, Python, PHP, Ruby, etc? Do any SQL language changes need to
be considered for implementation in these d
rivers?

None
.

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

18

of
35


2.14

IMPLICATIONS FOR OPE
NROAD

Does this feature have any implications for OpenROAD?
B
e sure to mention any
changes to ADF that are necessary to implement this feature, they often impact
OpenROAD.

Do any SQL language changes need to be considered
for
implementation in OpenROAD

None
.

2.15

DESIGN LIMITATION
S

AND ASSUMPTIONS

This section should list current limitations and assumptions made in the design.

If there are any dependent objects on the table or column being renamed then an
error message will be g
iven out and the rename operation will fail.

2.15.1

Dependencies

Does this feature depend on any external functionality (such as an XML parser,
or some other similar piece of code that does not belong to Ingres)? Does this
feature depend on another feature that w
ill be, or has been coded in this release
of the product? Describe the dependency.

None

2.16

PLATFORM SPECIFIC IS
SUES

Is there anything about this feature that causes it to have unique characteristics
or testing requirements when implemented on a specific platf
orm?

Are there any
platform limitations to this feature, or is it intended to run only on one platform?
Will the feature need to re
-
coded for other platforms (e.g. CL additions or re
-
architecture)

None

2.17

PRODUCT INTERACTION

Does this feature cause any change
s in the way that Ingres products interact with
each
-
other other than already detailed in the above sections? Are there certain
products that will/will no work with this feature (this is more relevant to tools such
as VDBA and new middle
-
ware servers)?

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

19

of
35


Non
e

2.18

PATENT INFORMATION

If there is any technology being developed for this feature that could be
considered for a patent, no
te the information here
.

None

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

20

of
35


3

EXTERNAL SPECIFICATI
ON

3.1

USER
PERSPECTIVE

In this section, the focus is on the tasks that a user will

perf
orm with this feature
.
Describe what the
feature

does and how it work
s form a user perspective
. Focus
on how it is used to perform the function d
escribed in the high level description
.



Provide screen shots
if appropriate

User will be able to rename a table

or a column

using this sql syntax.

I
f there are
any dependent objects on the table or column then the rename operation will fail
with errors.

3.2

INSTALLATION AND
ADMINISTRATION PERSP
ECTIVE

Include any special installation and setup tasks, system parameters o
r other
preparations that are necessary prior to use. Describe the steps needed to
setup and get the component going and any ongoing administration

that will
need to be performed if relevant. List all configuration parameters that apply to
this feature her
e.

None.

3.3

MIGRATION ISSUES

Describe any special steps
required to migrate from ex
isting versions
Ingres/OpenROAD

to this version

that arise because of this feature
. Does this
feature have any new catalogs or other implications for upgradedb?



Is the componen
t going to be backward compatible?



Can this version co
-
exist with an older version?

The new SQL syntax introduced will only work with the
new version of Ingres.


doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

21

of
35


3.4

SECURITY IMPACT

Does anything about the function need securing? Could it do any damage?
Could

it cause the display of sensitive information?

Does the implementation methodology do anything that produces a potential
security exposure
, such as run as root or Ingres (if this is an application)
?

None

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

22

of
35


4

INTERNAL SPECIFICATI
ON

4.1

ESTIMATED
TASKS AND
EFFORT

E
stimate the engineering effort to code and test the component ready for hand
over to QA and Technical Writing
. If it is a large function, break it up into smaller
“function points” and estimate each one.

For large projects, filling out the table
below and
should help but is not required.

Estimates should be effort to code
complete; that is engineering effort assuming 100% of an engineer’s time is
used, which will not normally be equal to elapsed time for the project. Estimates
should include time to:



Code t
he feature and all of the error checking required for the feature
(error checking may be up to 50% of the code in the DBMS)



Test your code and make corrections



Write and post an integration plan (or more than one for large projects)



Run HandoffQA for each
proposed submission and check the results

As a guide, an experienced engineer who already knows the code will normally
write and
sanity
test about 100 lines of code per day; engineers with less
experience

or those that are new to the code will write less.
Factor about 20% of
the time
it took to code
for final testing and fixes
. Look at existing modules to help
make an estimate of the number of lines of code required. Tasks should normally
be submitted as they are sane and complete, so the formula might be s
omething
like:

Time for task = (no_of_lines / 100) + 2 days for IP and HandoffQA

Total time = Sum (time for all ta
s
ks) + 20%

for overall testing and fixes

Click here to begin typing






doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

23

of
35


Task

Effort
(person
-
days)

Assigned to

Done
(yes/no)

Tes
ted
(yes/no)

P
arser

changes

1
0

Shubhagam

30%

No

Dm
f

changes

1
4

Shubhagam

30%

No

Qef changes

3

Shubhagam

No

No

Replicator changes

3

Shubhagam

No

No

Common changes

3

Shubhagam

No

No

Documentation.

1

Shubhagam

No

No

Testing

5

Shubhagam

No

No

TOTAL

39

-

-

-


4.2

PROGRAMMING

List
programs and

modules
written
, changed or deleted.
Initially this will be a
first pass estimate of what needs to be changed, it will likely change during the
course if the project. The version of this document at code complete will

contain
the modules or programs that actually changed.

Currently the following changes are expected for this feature.

4.2.1

Parser changes.

Provide a
short
description of

what the

module
does and how it changed if it was
altered.

Parser changes will be made to

parse the new Alter table rename syntax
introduced. The following changes are expected.

a.

psfparse.h:
define PSQ_ATBL_RENAME_COLUMN and
PSQ_ATBL_RENAME_TABLE.

b.

pslsgram.yi: Add parser changes for parsing alter table rename and
alter table rename column.

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

24

of
35


c.

psla
tbl.c: Add code to support psq modes
PSQ_ATBL_RENAME_COLUMN

and
PSQ_ATBL_RENAME_TABLE

new modules to support the rename of a table are needed.

4.2.2

DMF changes.

Following DMF changes are expected:

a.

Modify module dm2u_atable()


This is the main routine for alte
r table.
Add code for alter table rename column and alter table rename.

a.

Modify dmucb.h
-

Add defines for alter table rename and alter table
rename column.

4.2.3

QEF changes.

a.

Expect changes to qeus.c to support the new statements.

4.2.4

Replicator changes.

a.

Add support

to clean up replicator catalogs, for rename of
tables/columns registered with replicator.

4.2.5

Common!hdr!hdr changes.

a.

Expect new error messages, especially in erusf.msg to be introduced
for syntax checking etc.

4.3

COMPATIBILITY LIBRAR
Y INTERFACE CHANGES

Describ
e any changes made to the compatibility library interface. Any changes
described here should be copied to CL platform
reviewers

for approval before
changes are made
,

and the CL spec should be updated to reflect the new
interface
. Current platform reviewers

are:

Joe Abbate


VMS

Viktoriya Driker
-

Windows

Bob Bonchik, Hong Hwe


UNIX

Mike Touloumtzis
-

Linux

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

25

of
35


None

4.4

INTERFACE

How do other components that are external to the design interact with this
component? Describe methods and rules of interaction.



Communi
cation protocols
; is GCA affected? Other?



Changes of facility call interfaces in the DBMS (e.g. is dmf_call changed?)



Changes to the interface of non static functions



New error codes or error conditions that will be logged or propagated up the
stack to oth
er functions. Has the error handling for those functions been
updated?

To be determined.

4.5

BUILD IMPLICATIONS

Does this feature require any special jam rules? Did it require any changes in jam
MANIFEST files? Any new build targets? Any other build alteration
s?

None.

4.6

UI RESOURCE/PROPERTI
ES FILES

This section is largely relevant to GUI applications like OpenROAD and can be
removed for DBMS features.

Provide the names of the files required by the UI and Messages

File Name

Byte Count

Word Count

Format

Comments





















doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

26

of
35


4.7

BITMAP RESOURCES

This section is largely relevant to GUI applications like OpenROAD and can be
removed for DBMS features.

Provide the bitmap resources.

File

Comments










4.8

ICON FILES

This section is largely relevant to GUI ap
plications like OpenROAD and can be
removed for DBMS features.

Provide the icon files used..

File

Comments









Release note





System
requirements






4.9

PICCOLO CHANGE NUMBE
RS

Provide piccolo change numbers for changes made for this feature. Thi
s will be
filled in after the fact and should include change numbers for propagations of the
same change to other branches if appropriate

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

27

of
35



Change Number

Submitted to (code
-
branch)

Submission date


main




doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

28

of
35


5

IMPACT
AND DOCUMENTATION
SUMMARY

The estimates in

this section are approximate and are intended to give other
groups such as Tech
nical

Writing, Services,
Support and
QA an idea of the
impact this change will have.

5.1

PRODUCT/COMPONENT IM
PACTS

5.1.1

Entities

List the
tools
, commands, reports and messages that are
impacted by the
development of the module/function. Use the table below to summarize these
changes; you can refer to other sections for details
.

Entity

New

Modified

Comments

Tool




Commands




Messages




Help Modules





5.2

DOCUMENTATION

List the exist
ing end
-
user documentation that is affected by modules changes,
and
how it is affected
.

Be as specific and thorough as possible.

MANUAL

CHANGES NEEDED

Estimated
# of Pages


Installation Guide



Database Administrator Guide



System Administrator Guide



Connectivity Guide



SQL Reference Guide

Add documentation for
new SQL syntax.

Add
reference to Star
4

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

29

of
35


MANUAL

CHANGES NEEDED

Estimated
# of Pages


guide and replicator guide
about re
-
registering
registered tables after
rename.

Command Reference Guide



Migration Guide



Replicator guide

Add
note about re
-
registering the replicated
tables, upon rename.

0.5

Star Guide

Add note about re
-
registering the new table
name with the star
database if the registered
tables were renamed in
the local databases.,
upon rename.

0.5

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

30

of
35


6

QUALITY ISSUES

Look at t
he component from the QA point of view. Suggest any special tests
that will stress the component. Think how to make the component NOT work
and what special tests should be performed on this component. This is a
guideline to the QA testing procedures.

6.1

UNI
T TESTING SUMMARY

Testing individual functions or subroutines in isolation is called unit testing. Unit
testing in some cases requires the developer to use stubs and drivers.
Describe
the

unit testing you did in these sections.

Attach all unit tests to the

wiki page for
this feature so that they are available to QA.

Some of the unit test that are recommended for this feature are as below. This
list may be expanded in the future as deemed necessary.

6.1.1

Test simple rename operation on a table.

List
and unit test
ing planned or done.
.

1)

Create a table

2)

select the table id from iirelation.

3)

rename the table.

4)

select help for the table. Should succeed.

5)

select the old table from iirelation. This will fail.

6)

select the new table from iirelation. Should succeed.

7)

Note the ta
ble id of the new relation is same as the old relation.

6.1.2

Test simple rename operation on a table column.

List and unit testing planned or done..

8)

Create a table
with a column of any datatype

9)

sele
ct the table id from iirelation and column id from iiattribute
.

10)

rename the table

column using alter table rename column.
.

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

31

of
35


11)

select help for the table.
The new column name will show up.

12)

select the

tuple using

old
column name from iiattribute
. This will fail.

13)

select the tuple using new column name
from ii
attribute
.
This

s
hould succeed.

14)

Note the column

id of the new relation is same as the old relation.

6.1.3

Test rename of a system catalog using
the test
6.1.1
above
and
similarly test rename of a column of a system catalog from
the
test
6.1.2

above.

These operations should fai
l.

6.1.4

Test simple rename operation

(table or a column name)

on a

table
which is an

index.

Renaming an index table is allowed.

6.1.5

Test that only a table owner can rename the table

or a table
column
.

As user testenv try to rename the table

owned by I
ngres. This

test should fail with
errors.


6.1.6

Test that the new table name
or a table columns that
does not
already exist in the database.

Try to rename a table such that the new name is

name of a table already existing in the
database
. This test should fail with error
.

6.1.7

T
est renaming

a table

or a table column,

which
is a catalog,
gateway or a temporary table
.

Try to rename a table which is either a system catalog,

replicator catalog, or gateway or
session temporary table.

This should fail with errors.

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

32

of
35


6.1.8

Test renaming a t
able

referred in a view, procedure or a referential
integrity
.

Create a table, and then create a view referring this table, rename of the table should
fail. Repeat this test by creating a procedure and again by creating another a table that
references the
first table. Trying to renam
e

the original table should fail in each case.

6.1.9

Test rolling back a rename table operation.

This operation should work.

6.1.10

Test
that a
dropped column in the table can be used as new
column name in the rename column operation.

Cre
ate a table
with columns X and Y. Drop column X and rena
me column Y to X. Run
various queries on X to see if the queries succeed. Run modify on the table and run
some queries involving column X to see if there were any problems.

6.2

HANDOFFQA IMPACT

In this
section you should document expected or observed diffs in HandofQA
caused by the feature as well as other things that impact HandoffQA; should any
new tests be added to HandoffQA for this feature to prevent regression?

New handoffqa tests are needed to tes
t the new syntax. Existing tests are
unchanged.

6.3

TESTING RECOMMENDATI
ONS

Suggest other additional function tests that are necessary. Special test
requirements, for example: the security levels, hardware or software
configurations,

code page and multiple cod
e pages,

multi
-
system issues. Note
anything that cannot be tested
in a lab and
which might require field tests. What
can go wrong? How are these situations dealt with?

Try to rename a table with table names using il
legal characters, that are normally
not a
llowed in a table name. Similarly try to rename a column using characters
that are normally not allowed in a column name.

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

33

of
35


6.4

REGRESSION RISK ASSE
SSMENT

What would be the implications of failure in the component? Is the code
complex? What is the potential for

destabilizing existing functions?

What other areas of the product/component interact with this module?

None.

6.4.1

Backward Compatibility Issues

Is there anything that should be tested for backward compatibility? Does this
feature affect how a down
-
rev client c
onnects the current version of the DBMS?
Did the GCA protocol level change?

Is upgradedb required?

None

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

34

of
35


7

PACKAGING AND INSTAL
LATION IMPACT

Indicate any special packaging or installation requirements. Detail what the
packagin
g and installation requirements,
if any,
will be
.

Detail

any new files that
are required
, remember they should be added to the manifest, you are
responsible for doing this as part of the project.



None

doctorlanguid_4287da6a
-
f411
-
4726
-
966b
-
0c390ac186f0.doc






Page

35

of
35


8

SUPPORT IMPACT

Detail any diagnostics or trace facilities built in to the component

i
ncluding new
IMA objects, trace points, or other build time or run
-
time diagnostics
. Note
anything tha
t could be made into a good supportability tool. Note components
that are:



Difficult to diagnose (for example: no tracing facility
, dependent on specific
timing
)



Difficult to service

Include workarounds where appropriate.

Click here to begin typing

8.1

EXAMPLES AND TESTS

Detail any example or test code that you wrote during the development of the
feature that may be useful to help support, QA, or

customers to understand the
feature or useful to QA for testing. Attach all example and test code or details to
the wiki page for this feature

a.

Here are some examples of the SQL syntax using new ALTER table and
RENAME syntax.

i.

ALTER TABLE t1 RENAME TO t2

ii.

RE
NAME TABLE t
ab1

TO

tab2

iii.

ALTER TABLE t
est
1 ALTER COLUMN
col1 RENAME TO col2