Remove other schemas - Githubissues

GMOD / Chado

the GMOD database schema

http://gmod.org/wiki/Chado

Artistic License 2.0

38 stars 25 forks source link

Remove other schemas #123

Open spficklin opened 2 years ago

spficklin commented 2 years ago

It was proposed in our Tripal/Chado discussion this morning to move the frange, SO and genetic_code tables into the base schema of Chado and no longer have them separate.

This also requires adjusting the functions and views that may use these tables.

scottcain commented 2 years ago

As we discussed on the call, this is a big change, so we'll want feedback from as many people as possible before making this change. I suggest that we move the frange and genetic_code schemas in the the main schema and remove the SO schema altogether (I really doubt anybody is using them). We can implement each of these changes on separate branches and with separate pull requests.

The main motivation is to make it possible when creating more than one chado instance to have these tables "go along" with the rest of the chado. A good example of why this is necessary is genetic_code: you may create multiple chado instances each with separate genetic_code requirements. Additionally, there could be some overlap in feature names between chado instances in frange, so that schema shouldn't be shared among chados.

guignonv commented 2 years ago

I approve this change since it simplifies things when you work with multiple Chado instances.

Some additional notes on the impact of such a change:

For the "genetic_code" schema, it can be merged into the chado schema but chado.translate_codon() function will be modified to work with current chado schema (no "genetic_code." prefix in the function body).
For the "so" schema, if it is removed, chado.protein_coding_gene will be changed: in version 1.4*, this view is created and then replaced to use the "so" schema. It means that only the original version of the view will remain.
For the "frange" schema, it can be merged into the chado schema without any problem.

(as far as I know...)

spficklin commented 2 years ago

It seems this is a duplicate of issue #114

scottcain commented 2 years ago

I think this issue incorporates #114 but is more, so if one were to get closed, I think it should probably be #114

laceysanderson commented 2 years ago

Summarizing #114 here in preparation for it being closed as a duplicate.

Originally @scottcain thought these ancillary schemas (specifically frange) may be used by the GBrowse adapter but upon checking determined it is not.
@jogoodma confirmed that FlyBase is not using the frange table.
An email was sent to the mailing list in 2020 and no one spoke out as having used the frange schema.

laceysanderson commented 2 years ago

Additionally, confirming that KnowPulse does not use any of the ancillary schemas and I support these being moved into the main chado schema.