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

Engine allows conflicting table reservation specifications in TPB [CORE1777] #2202

Closed
firebird-automations opened this issue Mar 7, 2008 · 5 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Claudio Valderrama C. (robocop)

Assigned to: Claudio Valderrama C. (robocop)

As part of TPB accepted operations, it's possible to reserve tables for reading or writing, shared or protected. While it's possible that a user reading a TPB discovers that the same table was used twice with incompatible modes, when views are used, it's unrealistic to expect the user will discover the problem, since a view propagates it's locking types to the base tables and these tables in turn may be views, until the real, base tables have been hit. Since views can share tables or other views and different views in the same query can have different table reservation options, the engine doesn't complain: it simply assigns the latest table reservation it process to a table and overwrites any previous setting for the same table, silently.
This is related to CORE1600.

Commits: 04106dd

@firebird-automations
Copy link
Collaborator Author

Modified by: Claudio Valderrama C. (robocop)

description: As part of TPB accepted operations, it's possible to reserve tables for reading or writing, shared or protected. While it's possible that a user reading a TPB discovers that the same table was used twice with incompatible modes, when views are used, it's unrealistic to expect the user will discover the problem, since a view propagates it's locking types to the base tables and these tables in turn may be views, until the real, base tables have been hit. Since views can share tables or other views and different views in the same query can have different table reservation options, the engine doesn't complain: it simply assigns the latest table reservation it process to a table and overwrites any previous setting for the same table, silently. => As part of TPB accepted operations, it's possible to reserve tables for reading or writing, shared or protected. While it's possible that a user reading a TPB discovers that the same table was used twice with incompatible modes, when views are used, it's unrealistic to expect the user will discover the problem, since a view propagates it's locking types to the base tables and these tables in turn may be views, until the real, base tables have been hit. Since views can share tables or other views and different views in the same query can have different table reservation options, the engine doesn't complain: it simply assigns the latest table reservation it process to a table and overwrites any previous setting for the same table, silently.
This is related to CORE1600.

@firebird-automations
Copy link
Collaborator Author

Modified by: Claudio Valderrama C. (robocop)

assignee: Claudio Valderrama C. [ robocop ]

@firebird-automations
Copy link
Collaborator Author

Modified by: Claudio Valderrama C. (robocop)

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5 Alpha 1 [ 10224 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

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