Fastorm

Latest version: v0.0.17

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

Scan your dependencies

Page 1 of 3

0.0.17

- πŸ”¨ Work around for `pydantic` version` 2` being a thing. We now specify it to use `pydantic.v1` (if available, otherwise we assume it still is v1).

0.0.16

- πŸ”¨ Fixed a lot more stuff to make it now work quite nicely with FastAPI.
- πŸ†• Added a new `consume_from_row(row)` to make custom query result parsing easier.
- πŸ”¨ Fixed it not handling timezones in `datetime`s but instead breaking.
- It now converts everything it encounters to UTC first.
- For naΓ―ve `datetime` objects, that is assumed to take the computer's local timezone and is adapted for that to UTC as well.
- πŸ†• Take into account when you set `Field(default=123)` or `Field(default_factory=datetime.utcnow)` as value of the class field.
- πŸ”¨ Fixed `In[value, None]`.
- πŸ”¨ Fixed `field=None` in `select(…)` and `get(…)` not properly resulting in `field IS NULL`.

0.0.15

- πŸ”¨ Some fixes making it work with FastAPI.

0.0.14

- πŸ”¨ Fixed `REFERENCES` for more than one level of primary key references.

0.0.13

- πŸ”„ Made sure that the `async insert(…)` method contains no database-agnostic code, and that is actually refactored out to calls to new `_insert_preparation` and `_insert_postprocess` methods.
- This is in preparation of the sync version of the client.
- πŸ†• Make classes referencing themself possible.
- πŸ”¨ Fixed `DELETE` not working for primary keys which are references.
- πŸ”¨ Fixed `REFERENCES` to other tables with a double Primary key now set the `FOREIGN KEY` correctly in one, as opposed to trying to create `FOREIGN KEY` for each field.
- The old generated SQL would result in `ERROR: there is no unique constraint matching given keys for referenced table "<table name>"`

0.0.12

- πŸ†• Added a new `FastORM.get_primary_keys_sql_fields()` method to get the sql column name(s) of the primary key(s).
- ⚠️ Replaced the `on_conflict_upsert_field_list` parameter of `FastORM.insert(…)` and `FastORM.build_sql_insert(…)` with a new `upsert_on_conflict`.
- It is mostly the same, but the variable name speaks better what it does. That is, specifying the fields which it would conflict on.
- Migration:
- `on_conflict_upsert_field_list=['some_field', 'another_field']` is now `upsert_on_conflict=['some_field', 'another_field']`.
- `on_conflict_upsert_field_list=None` is now `upsert_on_conflict=False`.
- πŸ†• Also there's a new case now:
- `upsert_on_conflict=True`. Here it will now automatically use the primary keys to conflict on those.
- πŸ”¨ Fixed `FastORM.insert(…)` and `FastORM.build_sql_insert(…)` that a key listed in the conflict list for UPSERTs would not be excluded from the UPDATE part of the UPSERT, the value overwriting part.

Page 1 of 3

Β© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.