The JADE 2022 release meets tomorrow’s business demands.
There are occasions where a standalone environment is refreshed from a production environment in order to make ad hoc extracts from RPS relational views. For example, there are a couple of such cases (logistics and education) where such extracts have been used to develop predictive models.
These extracts can be performed from a primary database without requiring an RPS secondary node. This functionality is undocumented and has limited support. It is suggested that this functionality could be published and supported.
There are some extensions that are also suggested:
The current implementation does not allow a user-defined data pump application to be specified on the primary node. Sometimes such a data pump application is required. This restriction could be removed so that a standalone environment could be refreshed from a production environment and used to extract data without the need to implement a secondary environment.
A mechanism could be provided to extract the data in a .csv format, rather than the current .fmt and .tbl formats.
Julian Brown
We will put this under Future Considerations, but the implementation might be different.
Since you've essentially documented a feature you mention is undocumented, I'll mention for others, that what you're suggesting is only valid in certain scenarios, and it would be difficult for a developer to know when it's valid. The main concern I have is where user data is executed during the extract, during a column-mapping method or mapping method. The code can return different values on a primary or secondary, if the user logic is conditioned for that. Application initialisation can be different, too, and any logic that depends on that is also affected.
Maybe we could separate the Relational View aspect of this from the RPS aspect. It's perfectly reasonable to want to extract Relational View data, but I think it's not reasonable or safe to extract data according to an RPS mapping, on a primary.