Remove other schemas

[spficklin]

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]

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]

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]

It seems this is a duplicate of issue #114

[scottcain]

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

[laceysanderson]

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]

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