Dbbase

Latest version: v0.3.10

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

Scan your dependencies

Page 2 of 5

0.3.4

Change
* Added a paramater, `only_columns=True`, to `Model.deserialize` for filtering data to only data that pertains to columns. Up to now, `deserialize` for any class provided a generic means to convert JSON data into dictionaries with the option of converting the data from camel case to snake case. With this added parameter, `only_columns=True`, it is slightly easier to add dictionary data to create a model.

... python

example: id, and long_name are columns, other is something else
data = {
"id": 1,
"longName": "this is a name",
"other": "This is a test",
}

this would fail because 'other' is not a column
my_object = MyModel(
**MyModel.deserialize(data)
)

this would work due to the only_columns=True
my_object = MyModel(
**MyModel.deserialize(data, only_columns=True)
)

...

0.3.3

Add
* Added a utility function `get_model_defaults`. With this function a dictionary of keys and instanced default variables can be created. The intent of this function derives from wanting some portability and avoidance of interacting with a remote database until it is absolutely necessary, yet avoid rewriting class functions that are already written.

The idea is that use of the model instances would have all the methods, functionality, and comforts of home except for anything that connects to the database. One way to do this:

... python

from datetime import datetime
import requests

from dbbase import DB
from dbbase.utils import get_model_defaults

we use db only for creating the model
this results are sent to an API.
db = DB(':memory:')

class Table1(db.Model):
__tablename__ = "table1"

id = db.Column(db.Integer, primary_key=True)
start_time = db.Column(
db.DateTime,
default=datetime.now
nullable=False
)

def myMethod(self):
does something useful
returns answer

db.create_all()

defaults = get_model_defaults(Table1)
results in {"start_time": datetime obj here}

table = Table1(**defaults)

so there is a scaffolding in the form of the
table in which to use the object.

now it is time to send to the API.
post_res = requests.post(
url=TABLE_URL,
json=table.to_dict(),
headers={"Content-type": "application/json"}
)

...

Once the object is posted, the object will become part of the database with such things as the `id` assigned, any server defaults, etc will be created.

0.3.2

Change
* Corrected an issue when recursively documenting relationship variables that occasionally resulted in skipped variables.

0.3.1

Change
* Changed the documentation function for tables. Relationships settings. In the case of a relationship that is a single, not a list, the readOnly setting has been changed back to True.

In the case of a Parent model having a list of children, marking a related Child as not readOnly makes sense because a child object can be appended to a children. Upon saving such as model, both parent and children that have been appended will be commited.

In the case of a child relationship that is 'single', the append method is not possible, nor would the assigned id of a child make its way to the child_id of the parent. Therefore, for practical purposes it is marked readOnly: True.

0.3.0

Change
* Changed the documentation function for tables. Relationships had been treated as read-only for documentation purposes in the sense that an update process would naturally be focused on the explicit column variables for any given table. However, this neglects the possibility for bidirectional updates when the `back_populates` and `backref` feature is used. `doc_tables` now show readOnly True or False for related tables depending on how the relations are set. Since this breaks the previous `doc_table` function, the version has been bumped to 0.3.0.

0.2.8

* Added greater depth to documentation functions for relationships.

Page 2 of 5

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.