|
|
|
|
These Discussion Forums are dedicated to discussions on Sophis products. Some are private, you shall be connected to see their content.
For the benefit of the community and to protect the integrity of the project, please observe the following posting guidelines:
1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to Sophis products.
2. No Flaming or Trolling.
3. No Profanity, Racism, or Prejudice.
4. Publishing information for insider trades or other illegal trading is forbidden and will be reported,
5. Site Moderators have the final word on approving/removing a thread or post or comment.
6. English language posting only, please.
Private messaging between users is enable. If you already put a message on forums, a registered user can send you a private message by clicking on the username link, and thus on the "Message User" link on the "Private Messaging" row. The messages can be read by clicking on the Inbox button of the toolbar.
|
| |
|
|
 |  | |
| | |
| | |
|
|
 | | Previous |
| |
| Next | |  |
|
|
| |
 | | |
|
|
|
| Sophis to Sophis database migration |
|
|
Hi,
With my actual client, we are interested by asking Sophis to develop a new application, in order to prepare database migration. For instance, each time that Sophis provides a new version, or each time that the client provides a new toolkit plugin, the most problems are to prepare the configuration migration and all the deployment: binary files deployment is quite easy, but migrating configuration data from one database to another one is really difficult.
For example, such a tool could include:
-
a summary of all differences between two databases: a drill-down interface will be welcome
-
migration of data, in general cases:
-
destination database contains data that are not in the source database: deletion should be proposed, but not mandatory. A general behavior configuration will be welcome too: deletion or no change.
-
source database contains data that are not in the destination database: insertion should be proposed. Same behavior as for the deletion.
-
source and destination databases contain "same" data, but different on some fields or content: for instance, same yield curves or volatility curves contains points that do not exist or points do not have the same values. Same cases for instruments that not have the same fields.
-
should include migration of toolkit tables or fields related to the creation of instruments
-
migration of instruments: when new models are developed, in most cases, new instruments are configured in staging/integration databases. Such instruments corresponds sometimes to the real cases, and then, the end users want to see them in production too, after put in production of binary files, without doing the configuration again. Saying that the incremental differences betweeen two databases will be migrated is not enough. New models, tested but not approved, could be refused. So the tool should permit to choose which categories (allotments, models...) have to be migrated. If such instruments are contained as underlyings, instruments that contain them should be not migrated too. Special case could be done for packages: the tool could propose to migrate the included instrument with a quantity equal to 0 (- so i means that quantities of other instruments included in this package could be modified too).
-
migration of third parties
-
migration of market data: see general case and samples concerning the volatilties and yield curves. Places and currencies could be migrated too
-
migration of BO kernel stuff: only the configuration, not the payments, postings....
-
migration of deals and portfolio: should include relationships with the BOKernel: if the user decides not to migrate a deal or a folio, related BO Kernel configuration should not be included too.
Any participation from other Sophis clients is welcome...
Rgds,
Philippe |
|
|
|
| |
|
|
| Re: Sophis to Sophis database migration |
|
|
I forgot the users: sometimes, we have to test new user rights assignment in integration. Once applicated and tested, it could be nice to have it in production too. |
|
|
|
| |
|
|
| Re: Sophis to Sophis database migration |
|
|
|
In order to bring a visual description of the above requirements of the Sophis to Sophis uploader, the menu items could be the following ones:
The file menu could contain two items:
|
|
The database configuration could be done through, depending on how is developped the "differences" engine, webservices, for instance, when API is used, or through the user/password/server Oracle login. The folder of the destination and source installation folders of Sophis Risque/Value is perhaps required:
|
|
Preferences are needed to determine which objects should be analyzed, and how to detect that objects are different. For instance, saying that objects do not exist because internal codes (Oracle sequences) do not exist could be wrong. Differences between instruments and/or deals could be done through some field analysis and criteria to determine:
-
Instrument: two instruments could equal if internal codes -sicovam in the TITRES table - are equal, but not necessary. It could be on the reference, the external references and/or the name
-
Deal: tow deals could be equal if their internal code - refcon in the HISTOMVTS table -, but it could be on the place - it means folio and instrument- , amount, date, brokers and so on too.
-
Third parties: of course, the internal code, but the name and/or address too. For instance, a third party input as 'My Bankname' in a database and 'MB' in the other one should be considered as the same too
|
|
The selection of objects to compare could be done in the Preferences dialog as follow:
Concerning the date selection, it will concern, depending on the items it occurs:
-
for the currencies: yieldcurves, correlations and spot historical
-
for the instruments - interest rates included -, the volatilties, correlations and eventually spot historical
-
for the deals: the deals themselves, automatic tickets and electronic tickets
-
for the BO Kernel: postings, payments, instructions and confirmations
|
|
The results should appear as follow:
The results for each item could be the following ones:
- Children different: it means that the item is equal to the other one at the same level, but dependencies are different
- Different: the item exists in both databases, but some fields -not included in the eventual dependencies- are different
- Only in destination database: according to the rules of equality selected in the preferences dialog, the item is present only in the destination database
- Only in the source database
- Empty: items are equal
|
|
According to the selected item, several behaviors are enable: Copy - it means Insert or Update -, Don't copy - no change - , or Delete - if the item exists only in the destination database -. Update from the database to anothe one will take in account the selection of these behaviors. The default selection should be: Copy if item is different or exists only in the source database, Delete if the item exists only in the destination database. Of course,menu items enabling the reset and restoring the default configuration will be welcome. Update from a database to another one could be done at the different nodes of the hierarchical view, with the children ones or without them (only the selected item). If necessary, items that are different could showed as follow, by clicking on a contextual menu, "Show differences" item:
|
Updating certain fields and not all could be a "Nice to have". And in order to not display items that were already merged, an history of merge could be nice too. |
|
|
|
| |
| | |
| | |
| | |
| |
 |
|
|
|
|