Obevo’s configuration lets you define multiple logical schemas in a single system-config.xml file. And you are free to define as many system-config.xml files or logical schemas as you want to for your application.
The question is - how exactly should you map your physical schemas, logical schemas, and application products? This page will run through some options.
In the simplest case, your production physical schema is mapped to a single software product, which would define a single logical schema in your system-config.xml. You can then define multiple environments off this single logical schema, whether with multiple dbEnvironment entries in your system-config.xml file, or by tokenizing the system-config.xml file against different environments (but keeping the same logical schema list).
This is the example given to you in the kata.
If this works for you, then stick with it. The following sections will describe alternate cases, either:
A few requirements are needed for a team to consider managing multiple logical schemas in the same system-config.xml file. If all of the following do not fit for your use case, then consider keeping them separate.
Currently, the smallest unit of work for Obevo is the dbEnvrionment. Hence, each logical schema would get deployed for such environments.
i.e. If SCHEMA1 and SCHEMA2 are both found in your production environment, then you also expect them to be deployed together in all other environments
NOTE - this implies that only 1 primary DB type is supported for all environments in your system-config.
As one deploy execution would apply to all schemas, it is thus assumed that the same login would apply for all. This is particularly relevant for:
The multiple-schema setup can be useful to handle circular dependency issues across scheams, e.g.
Let’s start with the simpler use cases:
If the two schemas did depend on each other, then it would be hard to manage them separate due to the deploy order requiring deploys back and forth across the schemas.
Managing the logical schemas together in the same system-config.xml file will resolve the deploy order issue, as the deploy algorithm can handle any sort of deploy ordering.
A physical schema may be shared by multiple teams. The preference is to manage these as one logical schema and to deploy together (see the Onboarding Guide FAQ for justification of this).
That said - teams may still want to keep the files maintained in separate modules. If you choose this route, then at build-time, the various modules need to have their DDLs combined in one place so that Obevo can execute the deployment.
It is up to teams to decide how to merge across different modules. Ultimately, this depends on the build and dependency mechanisms that your team uses, and Obevo is agnostic of the build system teams choose to use.
If in the worst-case the teams that deploy to the same physical schema still do not want to deploy at the same time and want to maintain their own objects, then they can do so by simply defining different logical schemas for their objects.
Those logical schemas can still map to the same physical schema - Obevo is able to segregate the different logical schemas defined in a physical schema.
However, note that this involves a lot of complexity in your setup, notably around if you can truly guarantee that each logical schema is independent of each other in that physical schema (see the Onboarding Guide FAQ for more info). Thus, we highly discourage this route, but it is technically possible to implement.