changes to foreign keys in 4.1

[2x2xplz]

DBFlow Version: 4.1.0
Issue Kind (Bug, Question, Feature): Question

Please note if you are using Instant Run, there may be bugs where generated classes are not created. Ensure you are using
the apt or kapt plugins and that incremental compilation is off.

Description:

based on your reply to #1344

will be 4.1.0. in develop.

it appears that it should be possible to set a foreign key as non-nullable in 4.1+. However I continue to get the error Foreign Keys must be nullable during compiling.

Can you please provide a small code example (in Kotlin) of a foreign-key field set as non-nullable? Do I need to manually create a ForeignKeyReference for every foreign key (from (8) in the changelog to 4.1.0?) And if so, what values do I use for the other 2 fields?

Thank you.

[agrosner]

you're confusing the annotations. @NotNull is DB constraint annotation for non null. Nullable in Kotlin means that Foreign Keys must be nullable on the object. This is because foreign keys can validly be NULL in the DB even if you require it. From, Attempting to insert a row into the track table that does not correspond to any row in the artist table will fail, as will attempting to delete a row from the artist table when there exist dependent rows in the track table There is one exception: if the foreign key column in the track table is NULL, then no corresponding entry in the artist table is required.

[agrosner]

So if I did not place this constraint on the Kotlin code, then you could theoretically assign null on the field and cause runtime exception, or not be able to represent the relationship properly because you would be left with a non null object even though the relationship does not exist.

[2x2xplz]

Thanks for the pointer to the SQLite docs, I see what you are emulating. The requirement to use nullable variables was a change from the 4.0-beta release, so thanks for the explanation.

I guess what I'd hope to see is if a Column is annotated with @NotNull, then the associated Kotlin var could be a non-nullable type. You are a Kotlin dev too so surely you can understand that adding !! throughout the codebase, instead of using non-nullable values to begin with, makes it appear error-prone and sloppy.

Overall you have built a great library, this is just one of those edge cases where the DB model isn't perfectly aligned with the object model.

[agrosner]

I wouldn't use !!, I would use safe access wherever you need to use it in case it is null via. fk?.let { } .