Inheritance is not, to my mind, an HAS-A relationship
Agreed. With LEAF, a “IS-A” relationship is achieved with the extends attribute on BeanMetadata. Here is a useful page if you are interested in learning more on how this works in LEAF.
For clarification in LEAF terminology parent/child is used to refer to the HAS-A relationship created by a MetadataTemplate. Sub type and super type are used to reference an IS-A relationship.
How many ways are there to define HAS-A relationships? What are the PROS/CONS for each type?
There are 3 ways to create a HAS-A relationship between DataObjects
- Parent / child relationship with a MetadataTemplate (represented as DataObjectTrees)
Pros:
Child DataObjects are queryable with the benefit of having parentId and rootId calculated on the DataObjects. So if there exists Person objects that [HAS-A] Car, then I can query for cars that belong a Person of a specific ID.
Cons:
There is no concept of ordering
- ListOfDataObjects BeanMetadata field
Pros:
Order is maintained when persisted. Neatly nests DataObjects into other DataObjects
Cons:
These DataObjects cannot be queried and can only be retrieved by querying the DataObject that owns the ListOfDataObjects.
- Using a String or SetOfStrings FieldMetadata to reference IDs of other DataObjects
Pros:
DataObjects exist on their own and be queried individually
Cons:
You can’t query based on rootId / parentId so you will the DataObject that contains the reference ID and then load that DataObject.
data-object-editor in regards to DataObjectTrees
We do have plans to make a DataObjectTree editor but we don’t have a deliver date for that yet. The current limitation is the data-object-editor can only edit 1 data object at a time. Where as a DataObjectTree consists of multiple DataObjects. Most likely can compose together multiple data-object-editors to achieve your use case. I’d be happy to talk through this with you if you want.
Regarding Breaking Changes
To clarify, generally while developing, we would suggest just wiping the database if and when you’re going to make breaking changes, but that’s definitely up to your team to decide when and how to do that. Keep in mind removing fields or changing field types is a breaking change. Once you’re in production, though, generally those types of changes should be avoided, which is more what Mark was suggesting.