Dear all, I have written two implementations of polymorphic collection mappers.
These are the classes that are responsible for saving and loading collections of entities (where some entity has a collection of polymorphic entities). The first (PolymorphicForeignKeyInChildCollectionMapper): For each polymorphic implementation, creates a foreign key in the implementation table, to store the parent entity ID. Loading then occurs by iterating through all parent collection implementations and the all various implementations that belong to the parent are loaded. The second (PolymorphicForeignKeyInChildCollectionBaseMapper): Creates a table of the parent base type (even if it is abstract) and adds columns to store the ID of the parent, the concrete class type and the concrete class ID. Loading occurs by loading all rows from this base table, then for each row that belongs to the current parent, loading the child types from their respective tables and adding them to the parent collection. Side effects: The first: Load order can not be assured, as loading will be ordered by subclass order. The second: The base class item primary key ID is copied from the child primary key ID - I think this means that if you have two different collections of the same base class, you'll have an ID conflict if you save the same child item into both collections (but this can be fixed, if I create a ID version mapper just for this class, I think). Load order ought to be preserved. In both cases, as a particular class is used in more collections, columns are added to the child (or base) tables. Child entities should be able to exist in multiple (different) collections, but any child can only ever exist in one identical parent collection (two parents can't both have the same child in the same collection). Each implementation has issues and elegance problems, but I was wondering if you all have any opinions on which general method you prefer. In principle, I can make the choice run-time selectable (right now it is hard-coded). Is anyone aware of any specific pitfalls of either approach? Regards, Kevin PS: For properties, I'm using a method similar to the second implementation, except that the additional columns to store the property concrete class and ID are created in the "parent" entity table.
