Project

General

Profile

Feature #3870

enhance conversion and import to make it feasible for multiple OpenEdge databases to be merged into a single database in the converted system

Added by Greg Shah over 5 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
version_reported:
version_resolved:

History

#1 Updated by Greg Shah over 5 years ago

Customers often have artificially split their single logical database into multiple physical database instances. This has usually been done for historical reasons which no longer exist. The resulting installation is more complex and requires extra effort to manage/support. The 4GL code is also more complex as as result. When these customers want to simplify, they are often interested in "putting Humpty Dumpty back together again" with a single database implementation for the converted system.

Currently, we only have some facilities to drop or rename existing tables and fields within a schema. To implement merging of multiple database schemata into a single schemata will require changes to the conversion and the import.

I think this is largely about how to handle conflicts.

  • Duplicate table names but the contents of the tables have different meaning or otherwise represent different things.
    • It seems like renaming all but one of the tables would work.
    • All configuration and indexes can remain independent and we only need to remap the converted code.
  • Duplicate table names but the contents have the same meaning, then the data itself needs to be merged.
    • The structure of the tables may be different, how to handle this? For example, there may be fields that only exist in some but not all of the duplicate tables. Or the configuration of the fields is different.
    • Merging the data will be largely about handling conflicts as well, including IDs, uniqueness problems and duplicated data (that might have to be de-duplicated) .
    • Duplicate indexes that are the same can be dropped.
    • Duplicate indexes that have different structure or configuration need to be renamed to avoid conflicts.

#2 Updated by Eric Faulhaber over 5 years ago

Another concern is that ABL code may be written to explicitly CONNECT/DISCONNECT with a database that is to be merged into another. We currently have no way to deal automatically with the conversion of these statements for a database which no longer exists. ATM, I can't put my finger on exactly what conflicts various permutations of this scenario might cause, but some thought and design would need to go into this aspect of the problem.

Also available in: Atom PDF