In a ProductStore, there are three dataDocument fields:
I want to add a
DataDocument relationship for a category or store type of
I imagine that in the future, others will want to add additional types of
DataDocuments. Perhaps there should be a
ProductStoreDataDocumentAppl entity that connects the two entities with an
Enumeration instead of having individual fields for connecting the two for more flexibility.
What do you think @jonesde
Sure, with more of those it would make sense to use a join entity between ProductStore and DataDocument. For the entity name, as you suggested is great except we don’t really need the “Appl” on the end.
Most join entities are named for the two entities they join together. Join entities generally live with the ‘higher level’ entity. For example, orders are higher level than products or parties (orders use Product and Party, but each of those exists largely independent of OrderPart, OrderItem, etc). The join entity goes with the higher level entity, and should be named with both entity names together, starting with the higher level and followed by the lower level. In the proposed name you put together this would all hold.
FWIW, the extensions such as ‘Appl’ for Application in ProductFeatureAppl are based on the Data Model Resource book for consistency with it. In general I don’t like the pattern, though it sort of makes sense because ProductFeatureProduct or ProductProductFeature are a bit cumbersome. This is also weird because neither entity (Product or ProductFeature) is really higher level or more independent vs dependent… ie they both exist independently and are related to eachother using a join entity (ProductFeatureAppl). The same applies to others that relate an entity to itself, like ProductAssoc to relate two products.
One annoying part of this, and dealing with the old pattern meant for a small number of these, is to add support for the new ProductStoreDataDocument entity while retaining backward compatibility for those 3 fields on ProductStore (mostly just add to existing code while leaving the existing code functional). Perhaps at some point it will make sense to deprecate and eliminate those 3 fields, but that would take a while for proper notice (at least one minor or patch release to deprecate followed by at least one major level release to remove it, major level because it would not be backward compatible. Not that all software has to be managed that way, but it is more professional and makes Moqui more reliable to users (fewer surprises at least!).