[Progress Communities] [Progress OpenEdge ABL] Forum Post: RE: CI/CD for OpenEdge Databases: State or Migration?

Status
Not open for further replies.
P

Peter Judge

Guest
How do you handle this problem? Keep both the full schema and migration scripts (both for schema & data) in source control? Some kind of hybrid approach with full schema and rename files? I think you manage the schema versions as a unit - so there's at least one delta.df and possibly an update_after_delta_data.p. If you need to remove fields, you'll need a before_delta.df , an update_after_before.p, an after_delta.df and an update_after_after.p. All of which should be explicitly versioned. We followed this kind of approach in Dynamics back in the day. If you care to look at the approach we followed then, there's a set of files that define the updates, what should happen and when. For example github.com/.../icfdb102001patch.xml defines stuff after an "ADOLoad" but you can see there are PreDelta, Delta and PostDelta stages and they have some metadata too. There may be some doc on the DCU (Dynamics Configuration Utility) in the doc archives somewhere. So if you have a drop field, you'd add an update that would possibly add a new field ("Delta" stage) and move the field data from old to new ("PostDelta" stage). Then you'd create a Delta stage to drop the old field. There was code to deal with things like is this update re-runnable, does it only apply to new databases, etc. Take a look in github.com/.../dfd for the whole (or most of) ball of wax.

Continue reading...
 
Status
Not open for further replies.
Top