-
Notifications
You must be signed in to change notification settings - Fork 369
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Table primary composite key from Foreign Keys fails in 2.20 #3173
Comments
Thanks for the report! It's possible that this is a regression in 2.20.0 since that release contains new features for resolving references more easily, but I can't reproduce it with the tables you've posted alone. This file generates valid code for me: import 'package:drift/drift.dart';
part 'repro.g.dart';
class TransactionTransfers extends Table {
@ReferenceName('sourceTxUuid')
TextColumn get sourceUuid =>
text().references(Transactions, #uuid, onDelete: KeyAction.cascade)();
@ReferenceName('destinationTxUuid')
TextColumn get destinationUuid =>
text().references(Transactions, #uuid, onDelete: KeyAction.cascade)();
@override
Set<Column<Object>>? get primaryKey => {sourceUuid, destinationUuid};
}
class Transactions extends Table {
TextColumn get uuid => text()();
DateTimeColumn get date => dateTime()();
IntColumn get amount => integer()();
// etc, etc
@override
Set<Column>? get primaryKey => {uuid};
}
@DriftDatabase(tables: [TransactionTransfers, Transactions])
class Database extends _$Database {
Database(super.e);
@override
int get schemaVersion => 1;
} Are there any other references towards |
I'll work on trying to reproduce this with a smaller set of data. It will be a little bit before I have the time to experiment with and create a smaller reproducer. I encountered this issue on both Mac and Linux with Drift 2.20 for my app Reckoner. I don't have any data type referencing TransferTransactions, but there is a lot of references to various tables from other tables. You can look at the source to see my table setup for other red flags. I think I'm doing something a bit unusual where I use inheritance to keep the code DRY and make common functions for similar data types. For example, a table class called TrackedTable (not a database table) which creates uuid text field and overrides the primary key to be the uuid. I used this before you released managers and I've noted that managers don't seem to be generated at all/correctly for my database when I tried to use them. I'll probably just create a copy with the Reckoner Drift setup and remove things until I don't hit the issue anymore. On the upside, I can continue to build using 2.19 and I already setup my repo to fix my dependencies. |
Don't worry about finding a minimal case to reproduce it, I can also look at the entire repository and try to figure it out from there. Do you have a pushed commit somewhere that's pointing towards the state this was in when you ran into the error? Or can I just try to upgrade drift on |
It should be just as easy as checking out If you're cool with running my repo, you would just need to do Shouldn't need to install anything if testing on a mac. I just merged the v2.0.0 changes which add support for mac and iOS. |
Hm this is a tricky one. We currently expect the data classes to have getters for columns involved in references (because the reference functionality of the manager operates on resolved data classes, which generally makes things more intuitive for users). I've fixed it by just adding the missing getters here: diff --git a/lib/model/transaction.dart b/lib/model/transaction.dart
index 15df54d..085e72a 100644
--- a/lib/model/transaction.dart
+++ b/lib/model/transaction.dart
@@ -148,6 +148,9 @@ class TransactionTransfer extends Common<TransactionTransfer>
destinationUuid: Value(destination.uuid),
);
+ String get sourceUuid => source.uuid;
+ String get destinationUuid => destination.uuid;
+
@override
Object get key => (source.uuid, destination.uuid);
|
@simolus3 Is this my fault? |
Absolutely not, I was the one adding manager support to custom row classes. I don't think there's a general solution for this, but perhaps we can skip generating references code depending on whether the fields are present on the custom row class. I'll take a look. |
When I upgraded from Drift 2.19 to 2.20, I get build errors stemming from code generate for a table which has a primaryKey attribute formed from foreign keys. I have a financial tracker, so I implemented transfers by making them a table that holds a reference to two transaction keys and has a primary key defined by the composite of the two foreign keys.
When I try to build/run I get the following errors:
If I change the table definition and remove the foreign key references, everything compiles correctly and appears to be working based on my demo dataset.
What changed to make this setup fail?
The text was updated successfully, but these errors were encountered: