SCO Options /DMS-34051

jaspernygaard

Can SCO be configured with the following options:

1. Ignore cache?
2. Roles?
3. Context?
4. Directories?

Eddie D

Hi, thank you for your forum post.

Currently in the latest version of the product you cannot ignore:

• Cache
• Context
• Directories

You can filter Roles and 'Roles to programs' from the comparison results and subsequent deployment.

Currently in development and planned for a future release the ability to filter objects prior to the comparison taking place.

Do you have an example of what in regards to Cache, Context and Directories you are looking to be Ignored?

Many Thanks
Eddie

andersharder

Hi Eddie,
As a colleague of  jaspernygaard and the originator of this query let me elaborate.
There are actually 3 discussions in this.

1. Cache: 
cache option for tables is an operational directive that has no structural bearing on your datamodel. The reason it can be relevant to exclude is that is Oracle Edition dependent whether it is supported and thus destination dependent a bit in the same way as storage parameters are which you allow to ignore. 
This is a minor point and as we have a another way of handling this so this is not really an issue for us anymore. Nevertheless I believe it would be reasonable and simple improvement of SCO to have that as an option. I believe there are other Oracle Edition options that in the same way could be relevant to ignore, but the cache option is the one I have experienced so far.

2. Roles,  Context,  Directories (and users come to think of it)
A DB based system as the one we develop consists of many things. By bulk this is the user (schema) owned objects such as tables, indexes, packages etc which is handled by SCO. But there are objects that are in DB system level name spaces like Directories, Contexts, Roles and the Users (Schemas) themselves etc. 
It would be nice to be able to handle these objects (and the generation of scripts for deployment and maintenance of these) within SCO. 
I realize this is a quite substantial augmentation request and this will actually take SCO beyond what is in the name (*Schema* compare for Oracle) :-) 
For our needs, these are faily static as objects anyway and we can manage outside SCO.

3. Roles, privileges and the 'Cross-schema Permission' option
The 'Cross-schema permission' option restricts SCO to consider privileges for the objects it manages given to the schemas within the project. This is necessary to use this option if one works with Databases (instances) that host several systems (related to different SCO projects)
Even if SCO is not to handle deployment of the schemas (create user) themselves or roles or other system level component it would be beneficial if it recognized that a DB based system consist of more than the schemas and what they own.
Particularly when it comes to privilege management.
Typically as privilege management is done via roles.
It would be beneficial if one could give a list roles (in line with the list of schemas ones SCO project consists of) to the SCO project. Just so privileges on objects handled by SCO given to these roles are also managed when the 'Cross-schema permission' option is selected.
Further privileges for these roles (e.g. system privileges or for system level objects like dictionaries) is not part of this (that would be part of item 2 above).
For our needs this is the most important issue and it will require attention outside SCO for every deployment.


Hope this clarify things a bit.

Thanks, 
Anders

andersharder

deleted - duplicate

jaspernygaard

I've tried out the new pre-filter options and it works as expected. We will do migration scripts for the other objects types.