Allow nullable types in collections

[nielsenko]

Ultimately this is about supporting nullable primitive elements on realm lists, ie.

@RealmModel()
class _Player {
  @PrimaryKey()
  late String name;
  _Game? game;
  final scoresByRound = <int?>[]; // null means player didn't finish
}

@RealmModel()
class _Game {
  final winnerByRound = <_Player>[]; // I intended to support <_Player?> here as well, but alas core doesn't support it
  int get rounds => winnerByRound.length;
}

In the process I refactored how the generator lays out the schema, so it is now all done compile time with const constructable objects, so the above will generate Player:

class Player extends _Player with RealmEntityMixin, RealmObjectMixin {
  Player(
    String name, {
    Game? game,
    Iterable<int?> scoresByRound = const [],
  }) {
    _nameProperty.setValue(this, name);
    _gameProperty.setValue(this, game);
    _scoresByRoundProperty.setValue(this, RealmList<int?>(scoresByRound));
  }

  Player._();

  static const _nameProperty = ValueProperty<String>(
    'name',
    RealmPropertyType.string,
    primaryKey: true,
  );
  @override
  String get name => _nameProperty.getValue(this);
  @override
  set name(String value) => throw RealmUnsupportedSetError();

  static const _gameProperty = ObjectProperty<Game>('game', 'Game');
  @override
  Game? get game => _gameProperty.getValue(this);
  @override
  set game(covariant Game? value) => _gameProperty.setValue(this, value);

  static const _scoresByRoundProperty =
      ListProperty<int?>('scoresByRound', RealmPropertyType.int);
  @override
  RealmList<int?> get scoresByRound => _scoresByRoundProperty.getValue(this);
  @override
  set scoresByRound(covariant RealmList<int?> value) =>
      throw RealmUnsupportedSetError();

  @override
  Stream<RealmObjectChanges<Player>> get changes =>
      RealmObjectMixin.getChanges(this);

  static const schema = SchemaObject<Player>(
    Player._,
    'Player',
    {
      'name': _nameProperty,
      'game': _gameProperty,
      'scoresByRound': _scoresByRoundProperty,
    },
    _nameProperty,
  );
  @override
  SchemaObject get instanceSchema => schema;
}

Notice how schema is const constructed, and the strongly typed property types.

Dynamic realms, use _DynamicSchemaProperty and benefits by allowing me to drop getList<T> for just get<List<T>>, ie. not special property access needed for lists.

Resolves #163

[coveralls]

Pull Request Test Coverage Report for Build 3037342011

• 236 of 264 (89.39%) changed or added relevant lines in 16 files are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+5.3%) to 92.523%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
lib/src/type_utils.dart	4	5	80.0%
generator/lib/src/dart_type_ex.dart	3	5	60.0%
lib/src/utils.dart	2	4	50.0%
generator/lib/src/realm_object_generator.dart	8	11	72.73%
lib/src/realm_object.dart	67	73	91.78%
lib/src/realm_property.dart	28	42	66.67%

Files with Coverage Reduction	New Missed Lines	%
lib/src/realm_object.dart	2	86.67%

Totals
Change from base Build 3036688559:	5.3%
Covered Lines:	396
Relevant Lines:	428

---

💛 - Coveralls

[blagoev]

I think we are doing too much in this PR. We definitely need to have a discussion about the changes around the generator. I think we are putting too much responsibility into the generator which was designed to be lightweight and something we plan to replace in the future.

[nielsenko]

I think we are doing too much in this PR. We definitely need to have a discussion about the changes around the generator. I think we are putting too much responsibility into the generator which was designed to be lightweight and something we plan to replace in the future.

There is no more logic in the generator than before, it is just as fast as it has always been. It just lays out the generated code in a smarter way. It allows the runtime to skip work, because more is known compile time. I don't see how this in anyway will make it more difficult to transition to static meta-programming once it lands.

[nielsenko]

This is superseded by #902 and #903 which splits the feature implementation from the refactoring

[Shreedhar73]

@nielsenko Hello.
Is it so, Nullable types in Collections are only supported for local database ?

When i try to have a field of Type List<String?> it is throwing sync error.
Invalid schema change (UPLOAD): sync does not support collections of nullable primitives unless using the mixed type .

Is it the expected behavior or I am missing something here?

[nirinchev]

That is correct. The server team does plan to eventually add support but it hasn't been a highly requested feature and thus we don't have any timeframe for when we'll get to it. If it's important for your app, definitely reach out to your AE to clarify your requirements.

[Shreedhar73]

@nirinchev Thanks for Clarification.