Re: [Treebase-devel] Some results of testing with a user

[William P. <wil...@ya...>]

On Mar 19, 2010, at 12:07 PM, William Piel wrote:

> 
> On Mar 19, 2010, at 11:44 AM, Hilmar Lapp wrote:
> 
>> On Mar 18, 2010, at 8:06 PM, Vladimir Gapeyev wrote:
>> 
>>> (1) Unexpected different results on the Taxa tab -- a feature or a bug? E.g., find a single study, e.g. 10051. 
>>>     -- Click the study (which goes to Citation tab), then to Taxa tab ==> "Nothing to display"
>>>     -- Go to Matrices tab; click on "View Taxa" in the table ==> it goes back to the Taxa tab, showing lots of stuff
>>>     -- Go back to Citation tab; then Taxa tab  ==> "Nothing found to display" 
>>>    -- Go to Trees tab; click on "View Taxa" in the table ==> it goes back to the Taxa tab, showing lots of stuff.
>> 
>> This is for Bill to judge in terms of what kind of problem it may signal, and hence how severe it is.
> 
> This may be severe -- let's at least understand why it is happening. It is affecting a lot of studies.

I think I've figured out what's going on here. I took one taxon label that maps nicely and compared it with another taxon label that does not map nicely, and then I ran queries on tables related to these taxon labels. The main difference is that in the good case the taxonlabelset table has the correct study_id, while in the bad case the taxonlabelset has "2264" as study_id instead of "10053", which is what it should be. 

Last weekend I had solved this problem using an update query that assumed that study_id 10215 was the only "placeholder" for migrated records. Turns out that there seems to be another one: 2264. Vladimir, can you confirm that study_id 2264 is another placeholder? And if so, can you let me know if there are any other placeholder study_ids that I'm not aware of. 

If this is the problem as I think it is, the solution is the following update:

UPDATE taxonlabelset SET study_id = mx.study_id
FROM matrix mx JOIN taxonlabelset tls USING (taxonlabelset_id)
WHERE tls.study_id = 2264
AND mx.study_id <> 2264
AND taxonlabelset.taxonlabelset_id = tls.taxonlabelset_id

I vote that we run this on stage -- if that solves the problem, then we hand it off to Jon to run it on production.  Presumably Jon still has the data dump used in the transfer of data to production, so if anything screws up with can repopulate production. 

What do people think? 

The other difference is that the matrix associated with the bad one has version 0, while the other is version 1. Is there any rhyme or reason for the version fields that appear in lots of tables? 


Bill