Menu
▾
▴
#44 On gene name update, synonyms get duplicated
If the user modify a gene name a first time
(original_name=>1st_name), everything goes fine.
But if you modify it further, (1st_name=>2ndname) after
saving and reloading, the 1st_name synonym appears twice .
This might be a problem with
feature_synonym.is_internal in chado.
Logged In: YES
user_id=1349328
It's a bit more complicated than I expected.
Here is what I observe :
I am using a fresh single transcript, newly created and
saved back to chado, with one user added synonym (syn1).
So I load this transcript from chado modify it's name
(RICE001867=>foo) and save back. See the attached file for
the db trace.
Notice that because of the pub_id I get duplicates of some
synonyms, but only in the DB. In apollo, while I still see
the syn1 synonym, I don't see the RICE001867 synonym which
should appear.
And finaly, if I do foo=> bar, there is another duplicate in
the db, and I see the foo duplicate in apollo
Mark, what is the rule for displaying or not a synonym (I
think you implemented something for not displaying self syns)
Logged In: YES
user_id=422804
ok i think i know whats going on here - i think its due to
my recent change where i took out the self syns which i
think needs rethinking - i think when a new name is made
apollo makes a syn out of the old name and checks if it is
already a syn - if it isnt then it adds it as a syn - when
self syns were not being filtered the old name was present
as a self syn and thus the syn wasnt added - with the newly
self syns being filtered out it doesnt see the old name and
adds the old syn and then this gets inserted in db as well -
i think it gets inserted because pubs are different for self
and user syns - but actually feature_syn is an insert NOT a
force so it doesnt check if syn is present anyways (maybe it
should) - so i think the simplest solution here is to
reinstate the self syns - drop the filter as clearly they
were serving an unknown function - the other solution would
be to doing more checking on adding syns to the db but that
actually gets sticky with the pub ids - easier to just do
self syns - apollo doesnt check owner and i think thats ok -
one artifact will be that old "history" syns will have the
"none" self syn owner which i think is fine - in fact in a
quirky way it says this was the original name
Logged In: YES
user_id=422804
i took out self syn filtering in jdbc adapter and this fixed
this - i think this is ok for now - i dont think its a big
deal to incldue the self syns and clearly it was serving
this unknown alternate purpose - it might be nice to take
out self syns and have this all dealt with proper bit i
think that would be low priority