Private properties are ignored on Realm model generation

[dotjon0]

What happened?

So we have the below code. When we run dart run realm generate the _type property is not generated in the Realm .g.dart part file.... There is no warning message. Ideally it would be amazing if the Realm team could support private properties - use case below (can think of many more, please ask):

The outcome we are looking to achieve is to make 'enums' (stored in the database as a String) and instance of the enum via getters. So when you access Car.type it outputs a value from CarType enum.

@RealmModel()
class $Car {
  
  /// Car Type
  @MapTo("type")
  late String _type;

  @Ignored()
  CarType get type {
    return CarType.values.byName(_type);
  }
}

enum CarType { fastback, saloon }

Repro steps

See above

Version

^1.0.3

What Atlas Services are you using?

Atlas Device Sync

What type of application is this?

Flutter Application

Client OS and version

macOS 13.4.1

Code snippets

See above

Stacktrace of the exception/crash you're getting

None

Relevant log output

None

[nielsenko]

We hear you. For now perhaps rename _type to typeAsString and allow it to be public.

[nielsenko]

You don't need the @Ignored() on type as calculated props are implicitly ignored.

[dotjon0]

Thanks @nielsenko. Yes the typeAsString is a good suggestion, however we also need other custom getters to convert properties to different types in far more complex scenarios...so the property naming in these cases could get very unmaintainable and confusing... Is private properties something that you would consider as this would unlock a load of possibilities ?

[nielsenko]

We will definitely consider. Just have to think it through, but I don't see any immediate reason as why not to allow them.

Perhaps hidden behind a configuration flag.

[dotjon0]

Any updates on this please ? We have a huge number of enums (stored as strings in MongoDB Atlas) and the proposed approach above would be much appreciated to streamline the development and strictly typed nature - i.e. we can map 'strings' in Realm data base models to Dart enums.

[derrickgw]

It would be awesome to take this a step further and add support for enums directly and avoid the boiler-plate.

Annotations such as

@Enumerated(EnumType.ordinal32)

or

@Enumerated(EnumType.name)

Could be used the specify how to store the enum.

[nielsenko]

@dotjon0 This is now supported with 2.1.0.

@derrickgw I appreciate your suggestion, but one problem for us is that enums behave very differently across the various SDK languages. There are multiple issues requesting the same:

• Add support for enums realm-core#6159
• Enum support #681
• Support Enum types realm-dotnet#549
• Enums support realm-java#776
• Defining typescript schema with "extends Realm.Object" not support dictionary, embed model and linking objects realm-js#5260
• Enum type support without extra configuration realm-kotlin#829
• Support Swift enums realm-swift#921

It would be fairly trivial to add for the Dart SDK, but we exists in a larger eco-system. I will bring it up internally.

[dotjon0]

Amazing @nielsenko thank you soooo much! really appreciated! Will transform enums in Flutter Realm.

[derrickgw]

@nielsenko Thanks. I recognize that adding enum support at the file level would require a lot of effort and coordination. But in the meantime storing them as string or ints is essentially what we do now. Adding a dart-only annotation to automate that would be great, and might even make it easier to migrate later if/when the file format supports enums.

[dotjon0]

@derrickgw if you build your Realm models automatically, you can then automatically create the required setters and getters for enums, so likely the result you're after i.e.

@RealmModel()
class $Car {
  
  /// Car Type
  @MapTo("type")
  late String _type;

  @Ignored()
  CarType get type {
    return CarType.values.byName(_type);
  }
}

enum CarType { fastback, saloon }

[derrickgw]

@dotjon0
That is essentially what I have now, but the variable is statusInt and the getter/setter is for status because private variables weren't supported yet.
I am just saying that it would be awesome to have this boiler plate in the generated code instead of me writing it. It isn't a huge deal, just a nice to have. And it would allow the generated boilerplate to change if/when the database file supports enums natively.

[dotjon0]

@derrickgw yes in an ideal world for sure. Note there is an open feature request for this #681