anchor.diff:  before setting it to the pet. Then send it to the backend for persisting. The pet would still
   referered as the original type.
   
  -NOTE: This behavior is always important to remember. It stands for codes but also for views. Actually it's
  -the main behavior of views. Views are normally are parts of normal entities (selected non-list fields). Codes are like 
  -'views on themself' (this is also the reason why the Code interface overrides the generic of the
  -View interface).
  +NOTE: This behavior is always important to remember. It stands for codes but also for references to other entities.
   
   Codes have another speciality. Their initial values can be specified. This can happen in two ways.
   The first one is to have a csv - file with the same name in the same package as the Code class
  
positive.code: layer.
  
  The person field is declared final and must be initiallized. This means the Person is
  used as inline field. Inline fields don't get a DB table of their one. Their fields are
  added to the entity where the inline is used. The owner table looks like this:
  
  [source,sql,title="Log of table creation"]
  
negative.code: === Owner search page
  
  The OwnerSearchPage is a SimpleSearchPage. Why simple? Because the objects displayed are not a reduced version
  but the business entities itself. For complex entities with lots of depending or rerferenced objects it's a good idea to
  have a search entitiy (a view) of the complex entitiy. So you load only a small part of the data. Then when
  the user wants to display a single entity in its full beauty you have to reload the entity with all depending
  objects. Obviously for that you have to have two classes and the SearchPage needs exactly these two classes
  