Greetings everyone, I have a general question about how to handle deprecated objects.
We’re using liquibase (community and not the SQL-CL version) with an Oracle database. We’re using formatted sql change sets with a single XML controller file that sits at the top of our directory structure and does an includeAll
on each of the following directories in the desired order.
.
├── context
├── db_link
├── dml
├── documentation
│ └── images
├── foreign_keys
├── function
├── grant
├── integration
├── job
├── operation_scripts
│ └── certs
│ ├── fin
│ ├── ti-dev.drw
│ ├── ti.drw
│ └── wildcard
├── package
├── post_install
├── pre_install
├── privilege
├── procedure
├── python_utils
├── rest_module
├── role
├── seed_data
│ └── script_gen_util
├── sequence
├── synonym
├── table
├── temp_table
├── trigger
├── type
This is working great, but now I have a conundrum.
If an object (say, a package) becomes deprecated and we want to drop it, I’m wondering how to deal with this. Ideally we’d want the package to be removed from the database and for we’d like to be able to remove the package spec and body files from the source tree as well.
The same would hold true for a table, view, etc.
What’s the most common way of dealing with this?
My initial instinct would be to:
- Remove the script from its place in the tree
- create (or add an entry to) a post install script that drops the object(s) being deprecated - with the appropriate pre-condition checks
However, I feel that this would leave some “hanging chads” in the DATABASECHANGELOG
table. Is that something I should really worry about?
Thanks in advance.
Doug