Create a single datebase data loading format
Description
Activity
Sam Ottenhoff July 18, 2011 at 4:00 PM
No activity, closing.
Aaron Zeckoski December 27, 2010 at 4:51 PM
This issue has seen no activity in 10 months since the last MT review. If it goes for 1 year it will be closed as won't fix.
NOTE to MT members. If no activity before 23 Feb 2011 then close issue.
David Horwitz February 23, 2010 at 6:31 AM
MAINT TEAM REVIEW: This feature request is currently unassigned and will be reviewed. In line with stated Jira practice http://confluence.sakaiproject.org/display/MGT/Sakai+Jira+Guidelines Feature requests that are not going to be implemented will be closed with a status of "wont fix". If you intend implementing this issue please ensure that its up to date and assigned correctly
Stephen Marquard May 9, 2007 at 8:35 AM
I think there are lots of things that should be done by service API calls instead of SQL code, e.g. set up of the initial sites and pages (!gateway), and permission changes.
The initial db setup scripts and conversion scripts essentially break the abstraction model where each module is responsible for its own tables.
Ramaswamy Aditya May 9, 2007 at 7:47 AM
Particular situations are when inserting new data for DB updates needed for new versions of Sakai – for example the insert statement should not depend on a "known" order of fields but rather specify them explicitly:
insert into tablename (z, y, x) values ('a', 'b', 'c');
rather than
insert into tablename ('a', 'b', 'c');
in case the order of column creation was x, y and then z.
Maintaining separate, parallel sql files to do database updates is difficult, error prone, and a waste of time. Sakai should have a single format for describing data updates and use trivial preprocessors to emit data sql in specific dialects. This will eliminate work (and maintain consistency) in creating the different sql dialect files. It will also make customizing database upgrades for individual installations easier.
This is not a suggestion to create a universal language that subsumes all sql dialects. Dealing with variation in DDL statements is better done by hand, but much scut work could be eliminated by some simple perl scripts.