As an attentive reader you might have recognized that the minor version of the ObjectMapper changed from 1.1 to 1.2. That happend because of big changes within the new version of ObjectMapper .NET. But step by step.
The biggest change was the remove of the LINK ID used in Link Tables. The origin intention of the LINK ID was that the ordering of the items within a collection should remain untouched. That means after loading an object the items within the child collection should appear in the same ordering like they have been saved. This feature was fine, but almost unused by the developers. It only effected irritated database admins who wondered why the application did not run properly when the delete a link with LINK ID 3 in a collection from 0 to 5. That’s why I kicked it off.
In existing applications that means you have to migrate the content of your link tables and remove the LINK ID. Delete duplicate entries and setup the new primary key.
Example of migration Link Tables in Oracle.
— CREATE BACKUP TABLE
CREATE TABLE LINK_TABLE#COPY AS SELECT * FROM LINK_TABLE;
ALTER TABLE LINK_TABLE DROP PRIMARY KEY DROP INDEX;
ALTER TABLE LINK_TABLE DROP COLUMN LINKID;
— INSERT DATA
TRUNCATE TABLE LINK_TABLE;
INSERT INTO LINK_TABLE(PROPERTY, PARENTOBJECT) SELECT PROPERTY, PARENTOBJECT FROM LINK_TABLE#COPY;
— DELETE DUPLICATE KEYS
DELETE FROM LINK_TABLE
WHERE ROWID IN (SELECT ROWID
FROM (SELECT ROWID,
Row_Number() Over(PARTITION BY Parentobject, Property ORDER BY Parentobject, Property) Num_Dup
FROM LINK_TABLE )
WHERE Num_Dup > 1);
— CREATE PRIMARY KEY
ALTER TABLE LINK_TABLE
ADD CONSTRAINT LINK_TABLE_PK PRIMARY KEY (PARENTOBJECT, PROPERTY);
As an other change I removed the obsolete SmartPointer Pattern completly and added some new constructors that makes it easier to inherit the ObjectMapper .NET.
Furthermore I discovered a problem in our current project that forced me to think about the hierarchy level handling. Imagine you want to setup an email distribution list with a lot of contacts. So you own your distribution object and a collection that contains the contacts of that distribution. Due to the multi client capability (of our imaginated application) we must work with the optimistic locking functionatliy the ObjectMapper .NET offers.
Now we save the distribution list with all the contacts using hierarchy level 1 in order to save the link between both classes. Meanwhile saving the objects, an other user changes one of the contacts used for the distribution. And BOOM – we get an DirtyObjectException. Why? Because hierarchy level 1 instructs the ObjectMapper .NET to save the object itself and the dependent objects that are direct childs. That’s why we get a dirty object exception, because not only the link but also the object had been saved by the ObjectMapper .NET.
Since the current version the ObjectMapper .NET handles the hierarchy level more sophisticated.
- 0 means : Used to load or saved flat objects.
- 1 means : Stores a flat object and only the links to other objects.
- 2 means : Stores the dependent objects in the 1st level.
- 3 means : Stores the dependent objects in the 1st level including the links to the objects in the 2nd level.
- 4 means : Stores the dependent objects in the 2nd level.
Because this is hard to remind, I introduced some const values in order to make life more easy.
public class HierarchyLevel
public const int FlatObject = 0;
public const int FlatObjectWithLinks = 1;
public const int Dependend1stLvl = 2;
public const int Dependend1stLvlWithLinks = 3;
public const int Dependend2ndLvl = 4;
public const int Dependend2ndLvlWithLinks = 5;
public const int AllDependencies = int.MaxValue;
Furthermore I removed some faults that have been found in the last version. The attribute [StaticData] had been inverted. That means that the [StaticData] attribute did not mark the class as static data, but marked it as dynamic. This bug has been fixed now.
As a second thing I removed the overloaded method Equal and GetHashCode. Overloading this methods ended up in some strange failures due to the fact that different objects had been identified as the same because of their identical Id, even if they had been two different object references. This bug has also been fixed.
And last but not least I found the problem that the version attribute did not work as expected under certain circumstances.
Puh. That’s a lot of changes. Hope you enjoy my new version of the ObjectMapper .NET