- assigned_to: Kartik Mathur
Currently schemas are loaded through database scripts and the internal ID specified for a schema is exposed. The ID should be internal so the same schema does not need to have the same ID in each implementation.
We need operations for importing and exporting a schema. Exporting is needed in case an implementation adds element definitions in the database and wants to export it to share with or use in a different implementation.
The tables that need to be populated are:
metadata_schema_definition
mylead_schema_map
mylead_schema_ancestors
lead_metadata_categories
lead_attribute_definition
lead_element_definition
The import (and export) need a schema defined for loading the information and the XMC Cat builder should speak this format. Should this be xml or some other format? If XML, one downside is that it may be harder for human editing. If XML, easier to validate. If in a csv format, it would be easier for users to edit in Excel, but we could not embed it in a request as easily or validate the document being created/submitted.
The schema map definition table needs to be populated first. The Schema_name field is required to be unique, so:
1) need to check it is not already defined, if so send an exception to that effect.
2) determine a schema ID that can be used (needs a lock) and define using that ID.
The ID assigned is then used in all of the subsequent inserts as the schema ID.
The tables currently do not have foreign key relations (probably should - we originally started with myISAM tables). If we add foreign keys, no need for the import to make sure the dependencies are valid (e.g., are we defining an element that does not have a corresponding concept (attribute) ).
An issue is should it all be wrapped as a transaction or do a cascading delete if there is something that cannot be added?
Possibly there are two sets of operations needed - one set to import and export entire schema definitions, and a second set of operations for updating category, concept (attribute), and element descriptions. for example, on element definitions, it would be useful to have a means of updating the Element_description and Element_short_desc fields, but not change the internal IDs. The descriptions could be updated even if there is existing data, but the other fields should not be.