EDIT

@Andreas M.: Could you please double check this sql script?

CREATE TEMPORARY TABLE temp_ds_cleanup(
    type_designation_id int(11),
    original_ource_id int(11)
);

INSERT INTO temp_ds_cleanup(type_designation_id, original_ource_id) 
    SELECT tdb.id, osb.id FROM TypeDesignationBase tdb
    LEFT JOIN OriginalSourceBase osb on osb.id = tdb.designationSource_id 
    WHERE tdb.designationSource_id IS NOT NULL 
        AND tdb.typeStatus_id NOT IN (853 ,839 ,840 ,843 ,850 ,846 ,852 ,847 ,848 ,839 ,2108 ,2110 ,2111 ,2112);

-- SELECT * FROM temp_ds_cleanup;       

UPDATE TypeDesignationBase tdb SET tdb.designationSource_id = NULL 
   WHERE tdb.id IN (select tdc.type_designation_id FROM temp_ds_cleanup AS tdc);


DELETE FROM OriginalSourceBase WHERE id in (select tdc.original_ource_id FROM temp_ds_cleanup AS tdc);

DROP TEMPORARY TABLE temp_ds_cleanup;

If the condition from #note-9 is correct the query looks ok except for the fact that it does not include AUD tables which makes AUD and NON-AUD tables inconsistent.

Probably it is enough to run the UPDATE and the DELTE statement also on AUD tables and therefore pretend that the false citations never existed. But you know the specifics of this ticket better and maybe I am wrong.

wouldn't it be anyway much better to do such cleanup tasks in general via the DAO layer?

Andreas Kohlbecker wrote:

wouldn't it be anyway much better to do such cleanup tasks in general via the DAO layer?

This depends from case to case. In general I agree that if possible using hibernate and not SQL is preferred to be on the save side with AUD tables and other caching issues. So, of cours, you could also write a script using service or persistence layer.
In some cases, like model updates, it is very difficult to do so as the model is out-of-sync then.

For the given case it is definetely possible to write such a script if you want.

Ok, for model updates it may be problematic. I rather thought on all other taks, like data cleaning and so on, when I said "in general".
What is your personal policy for these taks? Do you accept inconsistent AUD tables or do you write java clean up apps in almost all cases?

I am asking since we should have a common strategy.

we have discussed this

1760 cases cleaned

"Data" tickets are usually not related to a target version once they are fixed. Therefore I remove it.