incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Meyer - KMZ" <>
Subject The SQL-OS: a question to everyone
Date Tue, 13 Sep 2011 17:25:06 GMT
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 

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?


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.

View raw message