Re: [Treebase-devel] [Treebase-guts] SF.net SVN: treebase:[687] trunk/treebase-core/db/cleaning

[Vladimir G. <vla...@du...>]

On Apr 15, 2010, at 2:22 AM, sfr...@us... wrote:

> Revision: 687
>          http://treebase.svn.sourceforge.net/treebase/? 
> rev=687&view=rev
> Author:   sfrgpiel
> Date:     2010-04-15 06:22:27 +0000 (Thu, 15 Apr 2010)
>
> Log Message:
> -----------
> Set of edits to the taxonlabel-taxonvariant-taxon tables.
>
> Added Paths:
> -----------
>    trunk/treebase-core/db/cleaning/2010-04-15_taxon_fixes/
>    trunk/treebase-core/db/cleaning/2010-04-15_taxon_fixes/README.txt
>    trunk/treebase-core/db/cleaning/2010-04-15_taxon_fixes/ 
> taxon_fixes_4-15-10.sql
>
> Added: trunk/treebase-core/db/cleaning/2010-04-15_taxon_fixes/ 
> README.txt
> ===================================================================
> --- trunk/treebase-core/db/cleaning/2010-04-15_taxon_fixes/ 
> README.txt	                        (rev 0)
> +++ trunk/treebase-core/db/cleaning/2010-04-15_taxon_fixes/ 
> README.txt	2010-04-15 06:22:27 UTC (rev 687)
> @@ -0,0 +1,17 @@
> +To apply, run taxon_fixes_4-15-10.sql
> +
> +--------
> +
> +These statements help clean up the mapping between taxonlabel,  
> taxonvariant, and
> +taxon records. They include INSERTS in which the primary key is  
> being supplied:
> +please verify that this is okay, or will it confuse Hibernate's  
> autoincrement?
> +
> +New taxon_id starts at 600001
> +New taxonvariant_id starts at 800000
> +
> +Please verify that these numbers are beyond the current highest  
> numbers.
> +
> +---------
> +
> +Apply changes as soon as convenient, because it is not impossible  
> that new submissions
> +in the interim will map to taxonvariants that this script wants to  
> delete.

.....
<rest omitted>

Bill,

I am sad to bring the bad news, but we need to be more careful with  
updates like this.   As you anticipated, inserting new PKs will  
confuse Hibernate, since the PKs the update creates are higher than  
the current values in the sequences that generate the PKs under normal  
operation.  The latter will catch up and clash eventually.

Can you modify the script that the INSERT statements do not specify  
the PK values?  Then the PKs will be properly generated by postgres  
from the sequences and Hibernate will be aware of that.  We went  
through some pains a few months ago to make this scenario possible!
When later in the script you need to know the generated IDs, I hope  
you will be able to look them up unambiguously via ubionamebankid and  
namebankid.

Will this work?

--Vladimir