Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deactivate Metadata-dependency-check [CORE1015] #1425

Open
firebird-automations opened this issue Nov 23, 2006 · 4 comments
Open

Deactivate Metadata-dependency-check [CORE1015] #1425

firebird-automations opened this issue Nov 23, 2006 · 4 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Michael Trowe (bubble76)

Block progress on CORE2486

Votes: 4

To work in existing DBs is sometimes very hard, if you do significant changes at the table-structure because there could be a lot dependencies in SPs or views.
It would be very useful to set the DB in a state where you can do every change without checking existing dependencies.
While doing changes only the touched objects will be checked if they are valid and only before bringing the DB online the complete DB will be compiled and checked if there are invalid dependencies.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 11348 ] => Firebird [ 15427 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Cosmin Apreutesei (cosmin_ap2)

I aggree... IBExpert has the "Recreate script" option as a workaround, but sure it's better to just invalidate dependencies, like in Oracle.

@firebird-automations
Copy link
Collaborator Author

Modified by: Sean Leyne (seanleyne)

Link: This issue block progress on CORE2486 [ CORE2486 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Volker Rehn (vr2_s18)

In Firebird versions < 3 it was possible to just delete from rdb$dependencies. Now, since system tables are read only, this option is gone.

Most of the time it is important to have dependencies checked by the database, but sometimes they need to be out of the way. Much like with indexes, which can be deactivated e.g. for bulk inserts and tthen activated again.

Typical use case for deactivated dependencies is an ETL database: hundreds of source queries, target tables, index definitions and - stored procedures, all interconnected. During an ETL run, many of the target tables are recreated (due to the lack of truncate, delete would be too costly, or due to the occasional additional field) and refilled. Stored procedures are there to bundle more complex ETL logic. To wrap SPs in packages and then empty/recreate their bodies is not an option, since they might be used in more than one place at the same time. The ETL data flow is run in parallel as much as possible. Delete from rdb$dependencies at the beginning of an ETL run has worked nicely for years.

So this kind of database is more like a scratchpad which needs many database mechanisms, but without dependency check. Dependencies are being rebuilt during the process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant