We don't want to depend on the database to load up data
about the models we define. We now leverage the existing
`aurweb.schema` module for table definitions and set
__table_args__["autoload"] to False.
Signed-off-by: Kevin Morris <kevr@0cost.org>
Now, we allow the direct relationships and their foreign keys to
be set in all of our models. Previously, we constrained this to
direct relationships, and this forced users to perform a query
in most situations to satisfy that requirement. Now, IDs can be
passed directly.
Additionally, this change removes the need for extraneous imports
when users which to use relationships. We now import and use models
directly instead of passing string-references to them.
Signed-off-by: Kevin Morris <kevr@0cost.org>
This rewrites the entire model base as declarative models.
This allows us to more easily customize overlay fields
in tables and is more common.
This effort also brought some DB violations to light which
this commit addresses.
Signed-off-by: Kevin Morris <kevr@0cost.org>
First off: This commit changes the default development database
backend to mysql. sqlite, however, is still completely supported
with the caveat that a user must now modify config.dev to use
the sqlite backend.
While looking into this, it was discovered that our SQLAlchemy
backend for mysql (mysql-connector) completely broke model
attributes when we switched to utf8mb4_bin (binary) -- it does
not correct the correct conversion to and from binary utf8mb4.
The new, replacement dependency mysqlclient does. mysqlclient
is also recommended in SQLAlchemy documentation as the "best"
one available.
The mysqlclient backend uses a different exception flow then
sqlite, and so tests expecting IntegrityError has to be modified
to expect OperationalError from sqlalchemy.exc.
So, for each model that we define, check keys that can't be
NULL and raise sqlalchemy.exc.IntegrityError if we have to.
This way we keep our exceptions uniform.
Signed-off-by: Kevin Morris <kevr@0cost.org>
This fixes SQLAlchemy warnings related to primary keys not
having an auto_increment or nullable.
We've done this by making all foreign primary keys nullable.
In ApiRateLimit's case, we can set a default str to act as
a null, which seems a bit more sensible.
Signed-off-by: Kevin Morris <kevr@0cost.org>
