Sqla-raw

Latest version: v1.5.1

Safety actively analyzes 629052 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 2 of 2

1.0.0

Hey hey, it's finally the official 1.0 release! Hopefully all the features and options are described in the README, but to try to summarize recent changes that got us to this point:

- SQL may be submitted as a string, by a path to a file containing SQL, or by file name using an automatic path-lookup convention
- Results returned as list of dictionaries by default. May optionally return a list of tuples, or a SQLA `ResultProxy` object instead
- Instantiates a single SQLA `Engine` instance per program run
- Complete set of unit tests
- Expanded README with fuller usage notes

1.0.0rc.1

Add `result_by_name()` method

Takes a file stem name, searches for it in a local directory (at `QUERY_PATH` or `${PWD}/query_files by default), and hands off to `result()`

0.5.0

Add `returns` arg to db.results() method
- can specify results as tuples or sqla ResultProxy object (see README for usage details)

Other changes:
- append application_name to DATABASE_URL
- add tests to get coverage up to 100%
- expand and revise README

0.4.1

Instead of catching database operational exceptions and returning them in a dictionary, which was the original behavior, — as of this release, database errors are simply raised as they would be if using SQLAlchemy or a DB-API driver directly. Logging exceptions was also considered as an alternative to raising them, but this decision to let them happen seems better and I have noticed it is in keeping with prior art in this area, such as Records or PugSQL.

The original behavior was included due to my concern that database errors can be hard to test for, and might occur due to missing or erroneous user behavior rather than due to software bugs. It might well be a bad idea, from the point of view of an application that uses this library, for execution to halt on such errors. Where that is the case, it now seems to me better for any code that calls `db.result()` to wrap that call in a try/except block, than for the library to attempt to anticipate this and catch the error itself.

Obviously, this could be a breaking change (I imagine it will be for Nerium) and any consumers should test their applications carefully when attempting to upgrade.

0.2.0

Adds `db.result_from_file()` method, which takes a path instead of a SQL string and reads the SQL from the file at path.

0.0.1

Page 2 of 2

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.