RDART-910: Add support for RealmObject.objectSchema

[nirinchev]

Fixes #1449

Replaces #1493

Depends on realm/realm-core#7426

[coveralls-official]

Pull Request Test Coverage Report for Build 8287079256

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 48 of 98 (48.98%) changed or added relevant lines in 5 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage decreased (-0.5%) to 86.097%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
packages/realm_dart/lib/src/configuration.dart	6	11	54.55%
packages/realm_dart/lib/src/realm_object.dart	10	18	55.56%
packages/realm_dart/lib/src/native/realm_core.dart	21	32	65.63%
packages/realm_dart/lib/src/realm_class.dart	10	36	27.78%

Files with Coverage Reduction	New Missed Lines	%
packages/realm_dart/lib/src/native/realm_core.dart	1	90.18%

Totals
Change from base Build 8287071322:	-0.5%
Covered Lines:	5778
Relevant Lines:	6711

---

💛 - Coveralls

[nielsenko]

It is unclear to me how dynamic schema changes will work in practice with generated realm models.

How can client code reasonably react to schema changes that invalidate the generated realm objects? Short of installing a new version, or go full dynamic, which sort of defeats the point.

Also, I wonder if we should distinguish between the schema "used" during source generation, and the current dynamic schema

[nielsenko]

What is this. How is that related to dynamic schemas?

[nirinchev]

Ugh, seems like something got left over when switching branches.

[nielsenko]

Should we separate it out? I guess it belongs to platform networking?

[nirinchev]

Yeah, I'll remove it.

[nielsenko]

Is the loss of const on this ctor here really needed? Isn't it only caused by the List.from call?

[nirinchev]

Correct, but I'm not sure how we can avoid the loss of const.

[nielsenko]

Of the top of my head, I think you can use a DelegatingIterable .. or just drop making SchemaObject iterable itself?

[nirinchev]

The problem is that we want the _properties list to be mutable - i.e. we're adding stuff at runtime. My understanding was that this is incompatible with const-constructed objects, but it's very possible I'm missing something.

[nielsenko]

Just because a ctor is marked as const doesn't mean it has to be used as such
with const arguments. Only that it can. If the backing list to DelegatingIterable is const, then you will get a runtime exception trying to modify it.

I guess that ties into my question, if we should track both the current schema, and the original schema used when generating the model. The latter could still be const constructed.

[nielsenko]

I still dream of using the flyweight property pattern from the old #903 PR 😄

[nirinchev]

The expectation is that the changes to the schema will be additive (if they're breaking, then you need to indeed reinstall the app).

For how that would be used - you can access the generated classes/properties as usual - the main change is that if you get a new property through sync, you can also access that by going through the dynamic API. Similarly, if there's a new object type that you didn't know about at compile time and that gets synchronized inside a RealmValue, you'd be able to introspect its schema and access its data.

[nielsenko]

...
For how that would be used - you can access the generated classes/properties as usual - the main change is that if you get a new property through sync, you can also access that by going through the dynamic API. Similarly, if there's a new object type that you didn't know about at compile time and that gets synchronized inside a RealmValue, you'd be able to introspect its schema and access its data.

I just struggle to see how an end-user can make good use of this in practice, without their code becoming overly convoluted.

Anyway, that is perhaps a bit unfair to this PR. A implies B.

I still think it could be beneficial to track the two schemas separately. Ie. the one used at build time, and the one currently in effect.

[nirinchev]

I agree, I don't think this should be something many people default to, but the use cases/annoyances would be similar to using a RelamValue - you'd need to introspect the schema and render things differently based on the type of the properties. An example would be an http server logging utility that logs some metadata for processed requests - e.g. the headers being sent. Then you can have a partially static/partially dynamic model that looks like:

class _HttpRequest {
  late ObjectId id;
  late DateTime timestamp;
  // ...
}

But then as requests are processed, columns are added dynamically for the different headers we see. Then they could do something like:

obj = realm.query<HttpRequest>().first;
for (const prop in obj.objectSchema.where(s => s.name.startsWith("header")) {
  switch (prop.propertyType) {
    case RealmPropertyType.string:
      const value = obj.dynamic.get<String>(prop.name);
      // Render value into the UI
	  break;
  }
}

[nirinchev]

@nielsenko I've updated this to not actually update the schema at runtime since that depends on realm/realm-core#7426 which is not resolved yet. I suggest we merge it as is since it represents a minor breaking change and we can add the autoupdating aspect as a follow-up PR.