We're working with a partner who want to keep a separate test instance with content tracking the (sizable) live repository fairly closely. The requirement that I've been given is to entirely replace the content from live every week or two.
Deleting 17,000 items (and over 20,000 bitstreams) is an all-day operation, and then comes the loading phase. It would save a lot of time if I could export the Community/Collection structure, EPerson and Group objects, registries, and anything else that's not an Item, Bundle, or Bitstream; drop and recreate the database; empty the assetstore and history; reload the noncontent tables; and then begin loading. So I'm looking at adding export/import for all of those objects, probably to XML. In the case of Community and Collection I guess the best thing would be to just do a single exporter producing the same XML dialect consumed by the existing Community and Collection Structure Importer. Likewise for the registries, it seems. The other classes would need importers built as well as exporters. Comments? Or is there a smarter way to make a consistent clone of a DSpace instance, with its own Handles, that is writable but doesn't affect the original? (The Handle business, plus the need to quiesce the production site to ensure consistency across database and assetstore, is why I don't just use tar and pg_dump.) -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Friends don't let friends publish revisable-form documents.
pgpHSF8yoCj3x.pgp
Description: PGP signature
------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects
_______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
