Fix `json_array_contains_value` function to use the `@>` operator for
checking if a JSON array contains a value in PostgreSQL. This is
necessary because the `has_key` function only works for string values.
Also, remove `get_rom_collections` method, as it was doing the same
thing as `get_collections_by_rom_id`.
Fixes#1441.
This change introduces PostgreSQL compatibility, by implementing the
following changes:
* Use `JSONB` instead of `JSON` for PostgreSQL databases. This is
achieved by creating a custom `CustomJSON` type that uses `JSONB` on
PostgreSQL and `JSON` on other databases, leveraging the variant
mechanism of SQLAlchemy.
* Add `is_postgresql` function to check if the current database is
PostgreSQL. Commonly used for migrations, but can be used to determine
how to build queries based on the database engine.
* Add `json_array_contains_value` function to check if a JSON array
includes a specific value. This function is needed as it's
engine-specific.
Support for PostgreSQL is on a best-effort basis, and it relies on the
community for continued support and testing. The project's main database
is MariaDB.
Closes#667.
The scanning process could try to fetch thousands of roms from the
database, one by one, which is very inefficient, especially when only a
few new roms are added to the library, as the overhead of database calls
is very high compared to metadata API calls.
This change introduces a new method in the roms handler to retrieve roms
by their file names in bulk, which is used during the scan process to
fetch a batch of roms at once, instead of one by one.
It also avoids the `@with_details` decorator when fetching roms during
the scanning process, as those details are not needed, and they were
adding unnecessary joins and data decoding.
The current implementation for some of the database handlers, where the
same method is used to retrieve either a single entity (when an `id` is
passed), a list of entities, or `None`, makes the typing and overall
design more complex.
This change simplifies database handlers, by having two separate methods
where appropiate:
* A method that receives an `id`, and returns either an entity, or `None`.
* A method that optionally receives filters, and returns (depending on
the current handler implementation) a list of entities, or a `Select`
object that allows chaining more SQLAlchemy operations.
