First steps to move to SQLDelight #47

It returns the result of apiCall, which is non-null.

Since we no longer inherit from classes like AbstractReceipt, the JSON utils must be added separately.

Removes the positionid of the add-on parent from the JSON and replaces it with just the addon_to ID. With SQLDelight, we can no longer directly resolve the relation with just the addon_to field, which means that we have to pass in either the ReceiptLine that addon_to points to or its positionid. Since the toJSON() is mostly used for logging purposes and the positionid is not strictly required, we can simplify the function here and add the equivalent of addon_to.positionid to the JSON afterwards in the caller where required.

Provide the same functionality as the getters on AbstractItem, but for the SQLDelight query result.

Android uses a different date format and requires the database version to be set correctly.

Uses the string representation of the double to create a BigDecimal. The previously used constructor on the other hand used the exact representation, which - to quote the docs - "can be somewhat unpredictable". This behaviour is also closer to requery's handling of decimal values. See https://docs.oracle.com/javase/7/docs/api/java/math/BigDecimal.html#BigDecimal(double)

Useful for downstream testing.

Aligns the data types with those used for other tables.

Some dates are stored as TEXT values in the database. Since they might contain unexpected values (such as "null"), it is more robust to handle them all through a single mapper class that performs consistent conversion.

Maps all 4 byte Postgres ID columns to Long in order to be consistent with the remaining code. See PostgresIdAdapter. Moves getLastInsertedId queries to separate compat .sq file to fix conflicting query classes being generated. The .sq files under sqlite/ and postgres/ are only allowed to contain the CREATE TABLE statements. Otherwise they generate another query class that conflicts with the ones defined in common/. The solution is to create a .sq file with a different name so that it generates a query class with a different name (such as compat.sq for CompatQueries).

SQLDelight has a machanism to sort create statements for a schema based on their dependencies. To achieve this, it creates a graph and sorts it topologically. During this process it only considers column level constraints. If a foreign key is defined as a table level constraint, the dependency is not considered. We were using table level constraints until now which resulted in create statements that were sorted alphabetically after file names. Since the .sq file names match their table names, calls to Schema.create() would fail on BadgeLayoutItem, which requires the table Item to exist.

This class now creates build problems when used in a Postgres project.

Now that the schema might be created by SQLDelight, all tables must be defined.

See #46

Use explicit parameter names to better distinguish between columns that reference a local ID and those that reference server IDs.

The SQLDelight Gradle plugin is causing trouble with other JREs and there is no more reason to run Gradle with older Java versions on this project.

Fixes multi-module builds that have a top-level definition of the protobuf plugin.

While server IDs should work just fine, it is still safer to use the tables' primary keys to refrence existing records.

Some of the migrated sync adapters are missing the event slug filter in runBatch that was present in the original version.

Improves readability and creates a better basesline for the next migrations.

SQLDelight does not like case differences between SQLite and Postgres. Since Postgres converts them to lowercase anyway, it's safe to use the SQLite naming.

The columns on CheckInList_Item and Question_Item have inconsistent definitions between Postgres and SQLite. On Postgres the are created as NOT NULL, which results in SQLDelight generating slightly different data classes between the two.

Makes the type of this column consistent with SQLite

It's a better fit than IllegalStateException.

Since we apply a scale of 2 when converting column values, we should avoid storing any higher precisions numbers.

Any changes to the adapter might also affect the conversions, so it makes sense to keep them in the same file.

With removed batching and the new insert()/update() methods, autoPersist() is no longer needed.

SQLDelight already uses the migration files to determine the DB version.

Question models were missing the getDependencyValues() override.

We were providing the wrong type of Instant.

Some query building code remains which should be migrated in a separate step.

SQLDelight returns the Long value directly on Postgres while it wraps it in a result type on SQLDelight.

…droid is too old for TRUE/FALSE (PRETIXPOS-1HH)

Since SimpleDateFormat is not thread safe, we might be running into race conditions here actually. Re-creating a new instance is expensive, so this is only a temporary fix while we validate a change to DateTimeFormatter.

Should guarantee thread safety without constantly re-creating formatters.

Reduces warnings when we convert them to models.

The change in cce5bf9 fixed booleans on older SQLite versions, but broke the queries for Postgres. This is a workaround that should make both databases happy. Since Postgres is extra pedantic in CASE epxressions, the complex order position queries had to be moved to the set of dialect-specific queries.

Updates with 1 instead of TRUE also don't work on Postgres.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

First steps to move to SQLDelight #47

First steps to move to SQLDelight #47

Commits on Nov 22, 2024

First steps to move to SQLDelight #47

Are you sure you want to change the base?

First steps to move to SQLDelight #47

Commits on Nov 22, 2024