[GUSDEV] Re: dbest_name in DoTS::EST

[Michael S. <msa...@pc...>]

Hi Fernan,

I'm sending this to both the GUSDEV and ApiDB lists since I think the answer
is useful to both audiences.

In general, the issue here is that the current (and soon to be released 3.5
schema) doesn't fully allow for representation of a particular domain.  As
discussed, one approach is to "massage" the data into the available schema,
but as noted, this is not ideal for numerous reasons including overall
compatibility, data model clarity, integration concerns, and so on.  The
only other approach then is to change the data model/schema to fully support
the domain.  You may do this locally, within your own GUS instance, or (and
much preferred) you may submit the changes to the GUS community for
inclusion with the GUS project.  This latter route is what I'd suggest in
this case.  The procedure for this is:

1) Create a ticket in the tracker with the proposed changes, being as
specific as possible.  SQL DDL is much appreciated.

2) Send an email to the list requesting feedback and comments on the change.
This allows the community to evaluate the change and work as a whole to come
up with the best solution.  Sometimes this step is not required for smaller
changes, and sometimes this step and the first step are switched in order.

3) Once the community has come to a consensus about the change, it will be
incorporated into GUS and included in the next release.  If you need the
change sooner, you may receive it by using a CVS release of GUS (assuming
GUS 3.5 here).

Hopefully this addresses the more larger issue and your questions as well.

Thanks,

Mike


On 5/31/05 1:42 PM, "Fernan Aguero" <fe...@ii...> wrote:

> +----[ John Iodice <io...@pc...> (31.May.2005 14:29):
> |
> | Maybe we can have it both ways, by immediately changing the plugins to
> | populate dots.ExternalNaSequence.secondary_identifier, and planning to
> | make the schema change (adding est_uid to dots.Est) in a future revision
> | (since it didn't make 3.5).
> | 
> +----]
> 
> Hi John and Michael,
> 
> as I just wrote to Deborah, I guess that source_id and
> secondary_identifier are used for accession and gi (i just
> asked her to see what is in those fields for dbEST entries
> or NRDB entries).
> 
> IF secondary_identifier is not used we can use it for the
> time being.  But that would be a hack.
> 
> I agree this would have to be in a future revision. Should I
> add it as a PR in the tracker?
> 
> Fernan