Frequently Asked Questions - dbdipview/dbdipview GitHub Wiki

The code does not depend on any special framework and a minimalist approach was pursued. However, the SQL queires should be free of any SQL dialect to minimize compatibility issues and the need for automated filtering them in the future. Data objects (SIARD, CSV) can be separated from the rendering part.

In the access module, the issues with errors in your SQL statements and configuration settings (queries.xml) can easily be resolved in debug mode. It has to be activated before the database is selected (e.g. http://server/dbdipview/login.htm?debug=123). The value for the debug parameter can be changed in the www/config.php file. Command-line utilities for database installation also have a verbose option for more detailed output.

They could be created in the original material – as long as you are comfortable with doing any changes in the original. Nevertheless, additional VIEWs can be created as part of the package configuration, and JOINs are used in the queries.

No. Data analysis and graphical rendering need to be done by some other tool if we need them. But so far we can verify the ingested database and check our basic understanding of its structure and content using typical queries, including the rendering of LOB objects. This is sufficient to provide access for many use cases.

All databases that have been activated as "public" are shown in the database selection dropdown menu. To access a non-public database, a user must obtain a direct link with the correct token for the database, e.g. http://server/dbdipview/login.htm?c=c5fb27ecea11c5. The access parameter and the token for a database are stored in www/data/config.json file as values for the keys "access" and "token" and can be changed according to your reading room policies.

Set the loginModeLevel variable in www/config/confighdr.php to force access with the code.

This file is typically generated by an external reading room application when the archivist confirms the order. The file contains all the metadata needed for the automatic installation of the database. The input files need to be made available in a special subfolder below $DDV_DIR_PACKED. In the ingest test phase, an order file can be used by the developer for quick re-deployments.

In many cases, only <siard> and <viewer> elements will be used, as in this examples. For all the elements that can appear when other packages are available, see the ingest project template in tools/template/package/Template_order.xml. Note that the filenames are usually preceeded with a subfolder name where all the input packages of a database are located.

<dbrequest>
	<order>Id of the order from the reading room</order>
	<reference>Id of the ordered Unit of description from the catalogue system</reference>
	<title>Title of the ordered Unit of Description</title>
	<dbcontainer redact="0">DBC4</dbcontainer>

	<siards tool="DBPTK">
		<siard>db1.siard</siard>
	</siards>
	<viewer>viewer.zip</viewer>
	<access>public</access>
</dbrequest>

If the redactdb.sql script is included as part of the package, it can be activated during the database setup. Set the attribute in the order XML file, or a special option in the menu.

admin/configa.php

some initial system configuration
(paths for input packages and unpacked files, external tools, username/password)

www/config.php

some initial system configuration
debug mode code

www/confighdr.php

database selection mode (via dropdown, database/container pair or code)
name of the institution or just any title
alt text for logo images on the first page (needed by screen readers)

www/local optional files (see README.txt for instructions):

mainVar.css -- colour definitions (will override www/mainVar.css)
logo1.png -- will be displayed on the top left corner
logo2.png -- will be displayed at the centre
logo3.png -- will be displayed on the top right

It is extremely easy to deploy or undeploy a database. In case we deal with very large databases, disk space issues may arise due to packages, or extracted files. After the deployment, most of them are not needed anymore.

The input files are usually in a special subfolder below $DDV_DIR_PACKED (see in configuration files above). If appropriate, the input packages can also be symbolic links to objects on other locations (disk drives). After deployment of a database, only the order file is still needed to enable easy undeployment. Other content of the subfolder can be removed if we need to free up disk space.

During the deployment, the extracted files will appear in a subfolder below $DDV_DIR_UNPACKED. After the deployment, the subfolder data can be removed, but the metadata subfolder needs to remain.

There is a naming convention for packages. Left part is archiv-specific and right part is: *_ddv.zip for viewer only packages, and *.eddv.tar.gz respectively for viewer plus CSV content packages. Each contains an XML file about.xml with the line <type>dbDIPview</type>. External packages (obtained from AIP) with SIARD or CSV files use the naming conventions of your repository. However, it is advised that for each ingest project you use the same naming conventions, e.g. using the ingest number 0001_...zip, 0001_...order.xml to enable easy overview when there are many databases (and files) managed on the same server.