|
Ray Davis made changes - 29-Jan-2008 13:04
Oliver Heyer made changes - 29-Jan-2008 13:28
I went back and looked at the original justification for the "sakai.demo" approach at
1. The OOTB default is for Sakai to run _without_ the "sakai.demo" system property set to "true", By definition, this means that not all of Sakai's capabilities can be demonstrated in a plain OOTB deployment. 2. The OOTB default CM provider is DB-based, but it doesn't write any sample data unless "sakai.demo" is true. This combination meant one of Sakai's capabilities that used to be demonstrable by default in 2.3 (course site creation) is no longer demonstrable by default in 2.4+. Since this takes away a very visible feature (albeit while adding access to many more features!), people got upset. A different but related issue is that the demo system needs some way to automatically keep its CM data "up to date" so long as course site creation is restricted to a current-date-based view of academic sessions. So here are a couple of possible solutions....
A) Instead of having the DB-based implementation be the default, make the OOTB default an almost-null non-persistent CM implementation which uses "sakai.properties" to define academic sessions. This returns us to more-or-less the pre-2.4 behavior but might break 2.4 and 2.5 installations... hmm, maybe not so good. B) Continue to make the DB implementation the default, but provide some easy optional way to create academic session records without bothering to create any other demo data. A Maven goal or a SQL script might be easy enough to produce, if that level of hands-on work is acceptable. Otherwise, we'll need to go with "sakai.properties" and all the usual "auto.ddl"-style cautions. C) For the binary demo, make "sakai.demo" true by default so that tables will always be loaded with demo data. Also, make the CM demo dataloader keep itself up to date with course site creation by adding new academic sessions and courses as time passes. C1) Actually, the simplest solution for timing-out would be to keep Worksite Setup's list of "current" terms static in the demo system rather than making it time-dependent. That way no changes would ever happen to a demo/QA system "behind your back". Which kind of seems like what we want with a demo/QA system....
Ray Davis made changes - 31-Jan-2008 09:52
As Yuji Shinozaki reminded me on sakai-dev, we already supply a way for non-Java-programmers to make changes to the default CM database: the ClassPathCMSyncJob Quartz job described under "Reconciliation" in:
https://source.sakaiproject.org/svn/course-management/trunk/xdocs/readme.txt This mechanism has a number of advantages over alternative suggestions: * XML is better for describing structured data than property strings are. * Quartz jobs can be safely run once without any further fuss. Safely using "sakai.properties" to update the DB usually means editing the configuration for just one server in the cluster, starting the server up, and then editing the configuration again before the next start. * Unlike web services or Groovy scripts, Quartz job management is available to Sakai admins by default in an OOTB deployment. The only issue I see with this approach as implemented in 2.4.x and 2.5.x is that it currently requires editing source and re-building, because the Quartz job set-up is commented out in "components.xml" and because the code reads its XML input from the classpath. I don't think it would be difficult to make the job always deployed but disabled by default, or to have it read from the file system instead. However, given how many other CM tasks are open and the lack of known customers, I'm reluctant to tack this extra work onto this task. So I'll hand it back to Oliver to decide whether to close it as a "Won't fix" or to create a new task for simplified CM Admin access via Quartz.
Ray Davis made changes - 31-Jan-2008 09:53
Oliver Heyer made changes - 31-Jan-2008 10:25
The Quartz Job can be uncommented. It won't run w/out a trigger.
It could easily use a file:/// URI to pull in the XML document from anywhere on the disk system. Our jobs use the location of sakai.home to find alternate configuration files ( alternate to sakai.properties ) which in turn can be used to configure the URI. By configuring the job to be reloaded each time it's run the configuration file is reloaded as well, This allows a Developer/Admin to edit the configuration file between runs... to point at alternate XML files. We load Subject/Departments as well as Rosters this way. What is the timeframe for 2.6? The timeframe for the official release probably doesn't matter as much to prospective users as just getting your improvements into the trunk, where they can then selectively be migrated to branches or used to create patches. Since you have more experience using this critter than I do (and since I'm supposed to be near 100% on Image Galllery right now), I think it would be great if you gave it a go -- thanks for thinking of it!
I wonder if a better example would be to steal the XML document format -- and do a quick Impl that plugs into the Federating Impl and allows both trees. I get concerned with anything that requires configuration or the amount of data we stick into the db being hard to replicate between environments or tiers.
Filter Maintainer made changes - 10-Jun-2008 14:59
Filter Maintainer made changes - 11-Jun-2008 07:21
Filter Maintainer made changes - 23-Oct-2008 05:50
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Closed
Major
Allow OOTB creation of course sites without the demo data load
"sakai.properties" comes to mind because that's how pre-2.4 Sakai defined terms. But since there are some well-known issues with using sakai.properties to update databases, it might be worth thinking about an alternative.
I'm going to link
SAK-12696to this since it seems possible that solving this issue can solve that one as well.