The documentation provides an example of one-to-many and the inverse relationship using a very simple example of scooters and scooter shop. However it doesn’t go into detail about the file structure.
Should both models be defined within the SAME file? This seems odd, as typically I would expect a file per model (with embedded models within the parent file). But I would not expect to have to define relationships in the same file, as files could get quite large and hard to manage.
However, I have been unable to get this working with seperate files.
Can anyone please confirm how relationships are expected to work with regards to the file structure and referencing children / parent?
You should use the same file.
Putting models in different files, will prevent you from linking between them, and you will loose the ability of updating them in the same transaction.
There are a few use-cases where it makes sense to split into multiple realms.
Thanks Kasper.
It seems strange to define models for separate collections in the same .dart file.
Would this be the most performative way of building these relations?
I did consider embedding, but using the example from the docs, whilst we need to provide a view of scooter shops and within, the scooters, we also need to query on mass scooters.
For example, we would need to say go and get all scooters of modal xyz.
It doesn’t appear you can directly get all where is an embedded object (unless I am missing something). Is there an efficient way of doing this?
Out of the 2 solutions (2 collections with relation vs 1 collection with embed) what would you say is the most performative?
Ben
Hi @Ben_Martin
I’m sorry, I must have misread you quetion on the fist pass, and sorry for the delay.
What I was trying to convey is that you should store all objects in the same realm file.
When it comes to the model classes you can use different .dart files for them, but if you need to link between models, you face the issue that the default prefix _ makes the class private to the file. Instead use prefix $ which will allow the model class to be visible in importing files.
Wrt. to getting embedded objects, you would query for the matching parent object, and drill into that to get the embedded part of interest. Think of embedded objects as part of an aggregate, they cannot exist outside of it.
Wrt. performance of embedded vs. normal realm objects it depends on the actual use-case.
It doesn’t make that big of a difference on the realm side, but on Atlas embedded objects are often cheaper.
Realm-side advantages of embedded objects is, that since they are part of a larger aggregate, you don’t have to setup subscriptions for them, and the lifetime follow their parents - ie. you don’t have to explicitly delete them.
I would suggest going with what best match the domain model. In your case I would not use embedded objects, as I suppose a scooter can move from one shop to another during its lifetime.
Thanks Kasper, this makes it much clearer. I think the Flutter SDK documentation could do with some additions, as there is some key information that you have provided here that isn’t immediately obvious or present in the documentation.
Since your responses, we now have a better understanding of how the embedding works, and use of parent or backlinks().
Realm is actually a really good product, it has just taken us some time to get our heads around it.