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

Introduce SQL statement abstraction framework #284

Merged
merged 8 commits into from
Jul 22, 2019
Merged

Introduce SQL statement abstraction framework #284

merged 8 commits into from
Jul 22, 2019

Conversation

jamadden
Copy link
Member

This accomplishes many things:

  • Makes it simple and easier to prepare statements, if desired. This replaces a whole bunch of nastiness spread through the MySQL and PostgreSQL code bases. That was the initial reason for this: a number of the polling statements needed to be prepared for improved performance (Rethink invalidation polling #159), but it was getting really ugly to deal with all the combinations. This made it easier to do so.
  • Abstracts parameter handling across drivers. This can eliminate many of the "meta variables" we (confusingly) use in conjunction with ScriptRunner
  • By having a schema definition in a single place, we can ensure all databases are consistent without editing three copies of schema.py
  • By having the schema definition represented in objects, we get import-time query validation when schemas change.
  • Simplifies dealing with the differences between history-free and history-preserving databases.
  • Help enforce certain query practices (e.g., Make the query abstraction layer enforce all 'FOR UPDATE' queries include 'ORDER BY' #282 )
  • Move a lot of datatype conversions (like driver.state_to_bytes() and the like) to a lower level to stop cluttering the main code (not implemented yet).

Ultimately this will mostly replace *_query_property and the use of ScriptRunner and lots of schema.py. That's only partly done here, though.

The main goal is to make it easier to automatically prepare statements and get rid of the nasty ad-hoc way we've been doing it.

Secondary goals are better readability, better refactoring (since we'll get compile-time errors if the schema changes) and easier cross-database and cross-history-state queries.
Begin an Oracle dialect to cover those differences, specifically boolean handling and named vs pyformat query args.
@jamadden jamadden merged commit 939ec45 into master Jul 22, 2019
@jamadden jamadden deleted the issue159 branch July 22, 2019 18:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant