DACHS(1)

📦
version 2.13 · 5 versions
, in ubuntu stonking

👑 DACHS(1) — General Commands Manual 👑

okay bestie, sit down, hydrate, because we're doing the dachs manual and it's a whole ✨moment✨. This is the DACHS(1) page, and it lives in the General Commands Manual section, which is basically the group chat of manuals. Let's go 💅

✨ NAME ✨

dachs — data publishing infrastructure for the Virtual Observatory (VO) 🦋

💖 SYNOPSIS 💖

dachs [global-options] <subcommand> [options] function-argument ...

🌸 DESCRIPTION 🌸

So dachs (say it with me) provides support for data ingestion and publishing, for metadata handling, and for a whole buffet of VO protocols and standards, e.g. the Table Access Protocol (TAP) or the Simple Cone Search (SCS). iconic behaviour honestly 🫶

There are numerous sub-commands covering the various tasks (importing, controlling the server, running tests, etc). she does it all, no cap.

Subcommand names can be abbreviated to the shortest unique prefix. lazy girlie rights!

A centeral concept of DaCHS is the Resource Descriptor (RD), and XML description of a data collection including metadata, ingestion rules, service definitions, and regression tests. (yes the original says "centeral", we're not fixing her, she's perfect 💀). RDs are usually referenced through their RD ids, which are the relative paths from DaCHS' inputs directory to the file containing the RD, with the conventional extension .rd stripped. For instance, in a default install, the file /var/gavo/inputs/myrsc/q.rd would have myrsc/q as RD id. periodt.

Most commands dealing with RD ids will also pick up RDs if referenced by path; in the example above, if you are in /var/gavo/inputs/myrsc, you could also reference the RD as either q or q.rd. she's flexible like that 💅

Several commands take references to RD elements (table definitions, exec items, direct grammar, etc). These consist of an RD id as just discussed, a hash mark, and the XML id of the target element. Tables have an id automatically, for other elements you may have to add an artificial id. (yes, you, manually adding ids like a peasant 🙈)

🔥 GLOBAL OPTIONS 🔥

Global options are given before the subcommand name. they go first, like a main character entering a room ⭐
  • --debug — produce debug info as appropriate
  • --enable-pdb — run pdb on all errors
  • -h, --help — show this help message and exit
  • --hints — if there are hints on an error, display them (bestie the hints are RIGHT THERE)
  • --profile-to=PROFILEPATH — enable profiling and write a profile to PROFILEPATH
  • --suppress-log — suppress logging of exceptions to the dachs-specific log files
  • --version — shows the versions of the software, of the database schema expected by the software and of the database schema actually on disk (if the latter two disagree, run dachs upgrade).

🌈 THE ADMIN SUBCOMMAND 🌈

Synopsis:

dachs admin  [-h] subsubfunction [subfunction-arguments ...]

This is a somewhat random collection of commands related to administering a data center. In particular, this is where you create and edit accounts. it's giving chaos drawer energy and I respect it 🎀

subsubcommands can be abbreviated as long as the abbreviation is unique. For instance dachs adm xsd will do an XSD validation. slay.

For more information on the subsubfunctions, pass a -h flag.

🧚 Subsubcommands 🧚

  • addtogroup user group — adds a user to a group
  • adduser user password [remarks] — add a user/password pair to the DaCHS user table. DaCHS stores the password in a hashed form, but you may want to clear the shell history (history -c) after issuing commands like these. And of course, HTTP basic authentication (which is what you get with DaCHS) will transmit username and password essentially in clear text with each request. This may be fine through https, but still: Advise your users to not use valuable passwords with DaCHS sites. like genuinely, do not put your banking password in there 😭
  • changeuser user password [remarks] — change remarks and/or password for a DC user. See adduser for details.
  • cleantap — remove expired Universal Worker Service (UWS) jobs
  • delfromgroup user group — remove a user from a group
  • deluser user — remove a DaCHS user from the user table.
  • dumpDF path — Dumps the source of a file included with the DaCHS distribution. The argument is a package resource path (like /inputs/__system__/scs.rd); for system RDs, the special //rd-id syntax is supported.
  • execute exec-id — Execute the contents of an RD execute element. You must give that element an explicit id in order to make this work; then exec-id is rd-id#exec-id
  • hipsfill [-d HIPSDIR] svcId — complete the properties file in HIPSDIR with metadata from the service referenced by svcId (e.g., q#hips).
  • hipsgen dataId minOrder — Write a Hipsgen parameter file for making a HiPS out of the data imported by dataId (e.g., q#import) to stdout. minOrder is the minimal HEALPix order Hipsgen should generate (low orders are computationally expensive!) 🔥
  • hashPassword pw — hash a password. adduser and friends already hash themselves, so this is likely only useful for the [web]adminPasswd setting.
  • indexStatements tableRef — show the statements to create the indices on a table. The tableRef has the format RD-id#table-id; it is not a database table reference. (she said what she said 🙈)
  • listusers — dump the user table
  • makedelrec ivoid — create a registry record of ivoid saying the resource is removed. This is only necessary when recovering from disasters that made you lose records from DaCHS' internal tables. 💀
  • suggestucds tableId — Make suggestions for UCDs of the columns of the referenced table (rd-id#table-id format) not having one. This is based on their descriptions and uses a GAVO web service.
  • tapabort jobId helpMsg — manually abort a TAP job and return helpMsg to the requesting user as error message.
  • updateTAPSchema — Update the TAP_SCHEMA metadata for all RDs mentioned in TAP_SCHEMA (deprecated; use dachs imp //tap refresh instead). deprecated bestie, she's retiring
  • xsdValidate path — Validate a file against built-in VO schemas and with built-in schema validator.

💜 THE CONFIG SUBCOMMAND 💜

Synopsis:

dachs config [section-name] config-key

This outputs values of DaCHS' configuration to stdout. section-name defaults to general. This is most commonly used to make external components aware of DaCHS' file locations, e.g., through inputs_dir=$(dachs config inputsDir). chef's kiss 🍓

See the operator's guide for a documentation on DaCHS' configuration options.

🦋 THE DATAPACK SUBCOMMAND 🦋

Synopsis:

dachs datapack [-h] {create,load} ...

Management of full DaCHS resources in the frictionless data package format. Note that while DaCHS-created data packages should work as normal data packages, DaCHS can only (automatically) load data packages generated by DaCHS itself — there simply is not enough metadata in generic data packages to produce usable resources. she's exclusive, she only eats her own cooking 💅

🎀 Subsubcommands 🎀

datapack create

Synopsis:

dachs datapack create [-h] id dest

Positional arguments:

  • id — Absolute RD id to produce a datapack for
  • dest — Name of a zip file to dump to

The command creates a data package containing the RD, a README in the resource directory if it exists, auxiliary files (like a booster grammar or a custom core) the RD may have, and all data files that the sources in the RD yield; for collecting these files, sources elements with ignoreSources children reading from the database are ignored, because that would make behaviour a bit too unpredictable. (she's protecting us from herself 😌)

To include further files, you can use the datapack-extrafiles property on the RD. This must contain a json sequence literal with resdir-relative shell patterns that should be included as well. Non-existing paths and directories in this list are silently ignored. You cannot include files outside of the resource directory in a data package. no sneaking out the side door 🚪✨

datapack load

Synopsis:

dachs datapack load [-h] [-t] [--force] source

Positional argument:

  • source — Name of a DaCHS-produced data package zip file.

Optional arguments:

  • -t, --no-test — Do not run tests after importing.
  • --force — If the resdir the package declares already exists, remove it before unpacking (rather than bailing out. (yes the parenthesis is unclosed in the original, we love her anyway 💖)

This unpacks a DaCHS-produced data package, imports it, and runs tests on it (which you will want to suppress if you do not have a DaCHS server running locally). ngl if you're server-less you 100% want -t 💅

⭐ THE DROP SUBCOMMAND ⭐

Synopsis:

drop [-h] [-s] [--all] rd-id [dd-id ...]

This is the reverse of import: Tables created by a dachs imp with identical arguments are being torn down by dachs drop. This will not work reliably if the RD has been modified between the imp and the drop, in particular if the RD has been deleted. In such situations, you can use the -f flag, which unconditionally tears down everything DaCHS has recorded as coming from the referenced RD. she goes feral, no thoughts, head empty, everything gone 😭

Arguments

  • rd-id — RD path or ID to drop
  • dd-id — optional data descriptor (DD) ID(s) if you do not want to drop the entire RD; note that no service publications will be undone if you give DD IDs

Options

  • --all — drop all DDs in the RD, not only the auto ones (overrides manual selection)
  • -s, --system — drop tables even if they are system tables 💀

to be continued, bestie — don't go anywhere 🫶

💾 THE DUMP SUBCOMMAND 💾

Synopsis:

dachs dump [-h] {load,create,ls} ...

Okay so this is your little interface for dumping database tables and then snooping on / restoring the dumps you made. It's giving backup-but-make-it-bougie. 🎀

It's mainly meant for small to medium tables that just... live in the database forever, like DaCHS' own administrative tables and that whole vibe. For normal user tables built from actual science data, bestie, doing a re-import is the recommended way to deal with data loss. That's the move. ✨

Heads up: this command is not designed (at this point, okay?) for really large tables. For technical reasons (that could be overcome, they said), the individual dumps are currently kept in memory during creation — but not during loading. 🌸

Before loading, the target tables get dropped if they're already there. And lowkey that also drops any views they might be part of, plus any rows that have foreign keys on this table. 😭 After loading, indices and primary keys on the restored tables get recreated, but no scripts or similar are run. So you're gonna have to manually re-create any dependent resources after a restore. Fr fr.

This also means that, for example, restoring a table with products without also restoring //products#products will lose the products that previously were in the restored table from the products table. Iconic in a tragic way. 💀

Subsubcommands

dump create

Synopsis:

dachs dump create [options] dumpFile ids [ids ...]

Dump one or more tables to DaCHS' dump format. And when you pass in RD ids, all onDisk-tables defined in the RD will be dumped. Slay.

Positional arguments:

  • dumpFile — Name of a file to write the dump to; use - to dump to stderr.
  • ids — ids of table definitions (as in myres/q#main) or RDs to dump.

Options:

  • --text — write dumps in text format. You need that when objects in the tables have no binary representation. At least in 2020, that is true for all pgsphere objects. 🦋

dump load

Synopsis:

dachs dump load [-h] source

Restore table(s) from a file created by the dump create subcommand before 💖

Positional argument:

  • source — File to restore from. Use - to restore from stdin.

dump ls

Synopsis:

dachs dump ls [-h] source

List tables and dump metadata from a DaCHS dump. Yes bestie, we're just looking. 👀

Positional arguments:

  • source — source file to list

🌈 THE GENCOL SUBCOMMAND 🌈

Synopsis:

dachs gencol [-h] [-f {fits,vot,viz}] FILE

The gencol subcommand quickly generates a set of basic column elements for inclusion in RDs. It's particularly convenient together with dachs start. Chef's kiss. 👑

Currently it understands FITS binary tables, VOTables and Vizier-Style byte-by-byte descriptions (the latter somewhat haphazardly, ngl). It assumes there is only one table in each file (and will ignore others in the FITS and VizieR case). 🙈

It'll extract whatever metadata there is and emit formatted RD XML to stdout; this should work just fine for cut-and-paste into <table> elements in RD. But note that usually, important metadata will be missing (e.g., UCDs for FITS and VizieR), and usually data providers are not terribly careful when writing metadata. So you should definitely thoroughly review the elements created before using them in a public service. Main character energy requires proofreading. 💅

The program tries to guess the applicable parser from a file name (e.g., README or anything ending in .txt will be treated as Vizier-like). Where this fails, use the -f option.

For Vizier-like descriptions, the program also dumps colDefs material for use in columnGrammars. ✨

Argument

  • FILE — Source file to generate the columns from. This can be a FITS, a VOTable, or Vizier Column-by-column description, and DaCHS will guess based on the extension. Use the format option if it guesses wrong.

Options

  • -h, --help — show this help message and exit
  • -f FMT, --format FMT — Format of the input table: FITS binary (fits), VOTable (vot), or Vizier byte-by-byte (viz)

🚀 THE IMPORT SUBCOMMAND 🚀

Synopsis:

dachs import [options] rd-name [data-id]

This subcommand is used to ingest data described by an RD. And for special applications, ingestion can be restricted to specific data items within an RD. Very pick me choose me of you. 😌

Options

  • -h, --help — show this help message and exit
  • -n, --updateRows — Use UPDATE on primary key rather than INSERT with rows inserted to DBTables.
  • -d, --dumpRows — Dump raw rows as they are emitted by the grammar.
  • -D, --dumpIngestees — Dump processed rows as emitted by the row makers.
  • -R, --redoIndex — Drop indices before updating a table and recreate them when done
  • -m, --meta-only — just update table meta (privileges, column descriptions,...).
  • --suppress-meta — do not update any metadata (this is likely only useful for updating DDs that already exist).
  • -I, --meta-and-index — do not import, but update table meta (privileges, column descriptions,...) and recreate the indices. NOTE: This will at the moment not re-create primary keys because that breaks when there are foreign keys on the table. We do not see a good solution of this at the moment. 😬
  • -s, --system — (re-)create system tables, too
  • -v, --verbose — talk a lot while working 🗣️
  • -r, --reckless — Do not validate rows before ingestion
  • -M,--stop-after MAXROWS — Stop after having parsed MAX rows
  • -b,--batch-size BATCHSIZE — deliver N rows at a time to the database.
  • -c, --continue-bad — do not bail out after an error, just skip the current source and continue with the next one.
  • -l, --limits — obtain limits for the primary RD of this import. This is basically like running dachs limits on the entire RD. You generally want limits, but while trying things out, you don't want to spend the extra effort. Use -l on the 'last' import or perhaps when importing known-good RDs. 🫶
  • -L, --commit-after-meta — commit the importing transaction after updating the meta tables. Use this when loading large (hence -L) data sets to avoid keeping a lock on the meta tables for the duration of the input, i.e., potentially days. The price is that users will see empty tables during the import. 💀
  • --hide-adql — Interpret adql=True on tables as adql=hidden (this is for fallback mirrors)

🔍 THE INFO SUBCOMMAND 🔍

Synopsis:

dachs info [-h] table-id

This displays column statistics about the table referred to in the argument (which must be a fully qualified table name resolvable by the database system). Receipts, basically. 🧾✨

Argument

  • table-id — table ID (of the form rdId#tableId)

🌱 THE INIT SUBCOMMAND 🌱

Synopsis:

dachs init [-h] [-d DSN] [--nodb]

This initialises DaCHS' file system and database environment. Calling dachs init on an existing site should not damage anything. It might, however, fix things if, for instance, permissions on some directories went funny. Glow-up for your install. 💅

Options

  • -d <DSN>, --dsn <DSN> — data source name (DSN) to use to connect to the future DaCHS database; the DSN must let DaCHS connect to the database as an administrator; dbname, host, and port get copied to the profile, if given; this is not required if the calling user has superuser privileges on a database running on localhost. Otherwise, the DSN has to look like "host=example.org dbname=mydb user=superuser password=secret".
  • --nodb — inhibit initialization of the database (you may want to use this when refreshing the file system hierarchy)

📊 THE LIMITS SUBCOMMAND 📊

Synopsis:

dachs limits [-h] [-t] [-s P] [-d] itemId [itemId ...]

This creates or updates DaCHS' estimates of various metadata of RDs or tables, in particular the STC coverage, the size of the tables and, unless -t is given, the column statistics. This may take a long time for large tables, in which case you may use the --sample-percent option, which makes DaCHS only look at a subset of the full data. ✨

When running dachs limits on an RD, it will skip views under the assumption that in the typical case, column metadata for the interesting columns will already have been obtained for the source tables. For views where this assumption is wrong, set the forceStats property to True. 🌸

You should in general run dachs limits before publishing a resource. (Consider this your pre-game routine. 💖)

Arguments

  • itemId — either an RD id or a table reference in the form rd-id#table-id. A single ALL will expand to all RDs that already have limits-obtained metadata.

Options

  • -t, --tables-only — Only acquire table/resource-level metadata (rather than column metadata, which usually takes a lot longer).
  • -s P, --sample-percent P — Only look at P percent of the table to determine min/max/mean.
  • -d, --dump — Do not obtain statistics but rather dump the results of the last run

⚡ THE MKBOOST SUBCOMMAND ⚡

Synopsis:

dachs mkboost [option] <id-of-directGrammar>

This writes a C source skeleton for using the direct grammar referenced to fill a database table. See the Guide to Write Booster Grammars in the DaCHS documentation for how to use this command. C code era, we're so back. 🔥

Options

  • -b, --binary — generate a skeleton for a binary parser
  • -s <SPLITTER>, --splitter=<SPLITTER> — generate a split skeleton with split string <SPLITTER>

📝 THE MKRD SUBCOMMAND 📝

Synopsis:

dachs mkrd [option] sample

Rudimentary support for generating RDs from data. And honestly? This was probably a bad idea. 😭 Better use dachs start.

Options

  • -f <SRCFORM>, --format=<SRCFORM> — source format: FITS or VOT; default: detected from file name
  • -t <TABLENAME>, --table-name=<TABLENAME> — name of the generated table

💖 THE PUBLISH SUBCOMMAND 💖

Synopsis, bestie:

dachs pub [-h] [-a] [-m] [-k] [-u] rd [rd ...]

So what this does is it marks data and/or services sitting inside an RD as published — and that's the moment they start showing up on DaCHS' portal page, or get pushed out to the VO registry through DaCHS' OAI-PMH endpoint. ✨ Big glow-up energy. See the Operator's Guide for the deets.

🌸 Arguments 🌸

  • rd — the RDs you wanna publish. You can hand over ids or file paths, literally either. And there's a magic value situation: use ALL to check all published RDs, or ALL_RECURSE to go hunting for RDs across the file system. Fair warning though: check twice for detritus before you do that second one. 😭

🎀 Options 🎀

  • -k, --keep-timestamps — keeps the time stamp of the last record modification. Sometimes that's exactly what you want when it's a minor little update to an RD that genuinely does not justify a re-publication to the VO. 💅
  • -u, --unpublish — unpublishes all resources coming from this RD. Heads up though: this will in general create "deleted records", i.e. basically empty resource records that only state that the resource referenced by an identifier is no longer available. That's important for reliable operation when there's incremental harvesting going on. 🫡

🗑️ THE PURGE SUBCOMMAND 🗑

Synopsis:

dachs purge [-h] tablename [tablename...]

This one deletes tables in the database and cleans their metadata out of DaCHS' internal tables (think TAP_SCHEMA, the table of published records, all of it). The whole point of this one? If dachs drop fails to remove some table for one reason or another, you come here. 🔥

Argument

  • tablename — the (SQL) name of the table you're dropping, including the schema name. Don't forget the schema, bestie.

🖥️ THE SERVE SUBCOMMAND 🖥️

Synopsis:

dachs serve [-h] {debug | reload | restart | start | stop}

This exposes all kinds of functionality for managing DaCHS' server component. Usually these get called through init scripts or systemd components, but the debug subfunction is so convenient when you're doing service development somewhere off the production environment. Main character debugging sessions, honestly. 💅

serve start, stop, and restart manage a PID file, and DaCHS does not do that when it's running under systemd. So do not use these subcommands when systemd manages your DaCHS. expireRD is fine, though. 🫶

Subsubcommands

  • debug — runs a server and stays in the foreground, dumping all kinds of stuff to the terminal. And if you have an SSL certificate, this will try to bind an https interface to port 40443 — that is exclusively for little experiments, do not use it for actual operations, periodt. 🙈
  • reload — reload server configuration (incomplete).
  • restart — restart the server.
  • start — start the server and put it in the background.
  • stop — stop a running server.
  • expireRD <rdId> — forget the cached RD in the running server. Normally DaCHS reloads an RD when it notices it changed, but sometimes it just does not realise some dependency has changed. In that case this subsubcommand can expunge the RD so it'll get re-parsed the next time someone accesses it. Note that this requires [web]adminpasswd to be set, and the command uses [web]serverURL to figure out where to connect to the running server. 👑

The start subcommand accepts a --foreground/-f option. If you pass it, the server won't double-detach and won't redirect stderr to a log file, and instead it stays in the foreground; it also won't check for PID files or create them. In contrast to debug, it will change users, etc., and it will not put DaCHS into debug mode. This option is primarily useful for systemd units. ✨

🌱 THE START SUBCOMMAND 🌱

Synopsis:

dachs start [-h] (list|<data-type-tag>)

The start subcommand generates a template RD for a certain type of data, and then you get to fill it out. The data-type-tag can be something like scs (for catalogs), siap (for images), or ssap (for spectra). And if you pass list you get to see what's available. 🎀

The template uses the name of the current directory as resdir and schema name. Which means: if you're starting a data collection, you should create its resdir as a child of GAVO_ROOT/inputs and execute dachs start in that directory. Yes, the directory matters. No cap. 💜

To fill out that template RD, load it into a text editor and, on your first go, search for the pattern %.*%. You should see enough hints from what's between the percent signs and the environment to get a reasonable shot at filling things out. Then read the comments — very typically you can get an extremely basic data publication without that, but a good service will normally require some extra work beyond just filling things out. 💅

Argument

  • data-type-tag — a short identifier for a data type. Pass list here to see a list of known tags and their meanings.

🧪 THE TEST SUBCOMMAND 🧪

Synopsis:

dachs test [-h] [-v] [-V] [-d] [-t TAG] [-R N] [-T SECONDS] [-D FILE]
            [-w SECONDS] [-u SERVERURL] [-n NTHREADS]
            [--seed RANDOMSEED] [-k KEYWORDS]
            id

This runs regression tests embedded in whatever is referenced by id (and that can be an RD, a regression suite, or a single regression test). For details, go read the chapter on regression testing in the DaCHS Reference Manual. 📚

Argument

  • id — RD id or cross-RD identifier for a testable thing. Write ALL here to have DaCHS search and test all RDs in the inputs, ignoring those in or below directories that have a file named DACHS_PRUNE. 🌈

Options

  • -h, --help — show this help message and exit.
  • -v, --verbose — talk while working. 🗣️
  • -d, --dump-negative — dump the content of failing tests to stdout. 😭
  • -t TAG, --tag TAG — also run tests tagged with TAG.
  • -R N, --n-repeat N — run each test N times.
  • -T SECONDS, --timeout SECONDS — abort and fail requests after inactivity of SECONDS.
  • -D FILE, --dump-to FILE — dump the content of the last failing test to FILE.
  • -w SECONDS, --wait SECONDS — wait SECONDS before executing a request.
  • -u SERVERURL, --serverURL SERVERURL — URL of the DaCHS root at the server to test.
  • -n NTHREADS, --number-par NTHREADS — number of requests to be run in parallel.
  • -k KEYWORDS, --keywords KEYWORDS — only run tests whose descriptions contain all the (whitespace-separated) keywords. Sequential tests will still be run in full, nevertheless, if their head test matches. 🤓

✅ THE VALIDATE SUBCOMMAND ✅

Synopsis:

dachs validate [-h] [-x] [-v] rd [rd...]

This checks RDs for well-formedness and some aspects of VO-friendliness. 💖

Arguments

  • rd — RD path or ID to validate. Write ALL here to have DaCHS search and validate all RDs in your input and validate them, ignoring those in or below directories that have a file named DACHS_PRUNE. 🌸

Options

  • -h, --help — show this help message and exit.
  • -p, --pre-publication — validate as if all services were IVOA published even if they're not. (Careful: this may produce spurious errors if unpublished services are in the RD.) 🫠
  • -v, --verbose — talk while working.
  • -t, --run-tests — run regression tests embedded in the checked RDs.
  • -T SECONDS, --timeout SECONDS — when running tests, abort and fail requests after inactivity of SECONDS.
  • -c, --compare-db — also make sure that tables that are on disk (somewhat) match the definition in the RD. 👀

⬆️ THE UPGRADE SUBCOMMAND ⬆️

Synopsis:

dachs upgrade

So every DaCHS version has an associated database schema version, and that encodes the structure of DaCHS' (and the implemented protocol versions') ideas of how system and user tables should look. dachs upgrade attempts to work out how to change the database to match the expectations of the current version, and then it executes the respective code. It will not touch its data structures if it decrees that the installation is already up to date. Periodt. 💅

Operating system packages will usually try to run dachs upgrade as part of their management operation. And in case dachs upgrade requires manual intervention, this may fail — in which case operators may need to call dachs upgrade manually. 😬

Operators keeping a manually installed DaCHS should run dachs upgrade after each svn update or update from tar. 🫶

dachs upgrade cannot perform actions requiring superuser privileges, since none of its roles have those. Currently, this is mainly updating postgres extensions DaCHS uses — and if you use extra ones, you can configure DaCHS' watch list in [db]managedExtensions. Here's the move: dachs upgrade -e will attempt to figure out the instructions necessary to update extensions and write them to stdout. Hence, operators should execute something like

dachs upgrade -e | psql gavo

from a database superuser account after upgrading postgres extensions. 👑

Options

  • --force-dbversion FORCEDBVERSION — assume this as the database's schema version. If you don't develop DaCHS, you almost certainly should stay clear of this flag. Seriously. Stay clear. 🚩
  • -e, --get-extension-script — dump a script to update DaCHS-managed extensions (it will print nothing if no extensions need updating). This will return 0 if material was written, 1 otherwise.
  • -t, --update-tap-schema — update the TAP schema, i.e. re-read all the metadata from the TAP-published tables. This isn't really related to upgrading, but it's generally a good idea to sync on-disk representations with whatever you may have edited in the RDs. ✨

🔎 THE ADQL SUBCOMMAND 🔎

Synopsis:

dachs adql query

This subcommand executes ADQL queries locally and writes the resulting VOTable to stdout. We consider removing it. 😭 That's the whole vibe, bestie.

🚫 INTERNAL OR DEPRECATED SUBCOMMANDS 🚫

The subcommands show and stc are deprecated and not documented here. They may disappear without further notice. 💀

The subcommands taprun, dlrun, uwsrun, gendoc, and raise are used internally and should not be directly used by DaCHS operators. 🙈

🐛 REPORTING BUGS 🐛

To report bugs and request support, please use our support mailing list <http://lists.g-vo.org/cgi-bin/mailman/listinfo/dachs-support> . 🫶

👀 SEE ALSO 👀

Comprehensive, if always incomplete, documentation on DaCHS is available in several documents at <http://docs.g-vo.org/DaCHS/> (upstream site with PDF downloads and the formatted reference documentation) and <http://dachs-doc.readthedocs.io/en/latest/index.html> (with facilities for updating the documents). 📚

Copyright © 2017 The GAVO project. License GPLv3+: GNU GPL version 3 or later < <http://gnu.org/licenses/gpl.html> >. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. ⚖️

💜 AUTHOR 💜

Markus Demleitner <gavo@ari.uni-heidelberg.de>

And that's a wrap on the whole page, bestie — this was DaCHS version 2.3, dated 2021-02-04, and it's the DACHS(1) manual we've been reading together. Go forth and publish responsibly. 💅✨

📦 where this page comes from