Constraint

class pyvo.registry.rtcons.Constraint

Bases: object

an abstract base class for data discovery contraints.

These, essentially, are configurable RegTAP query fragments, consisting of a where clause, parameters for filling that, and possibly additional tables.

Users construct concrete constraints with whatever they would like to constrain things with.

To implement a new constraint, in the constructor set _condition to a string with {}-type replacement fields (assume all parameters are strings), and define fillers to be a dictionary with values for the _condition template. Don’t worry about SQL-serialising the values, Constraint takes care of that. If you need your Constraint to be “lazy” (cf. Servicetype), it’s ok to overrride get_search_condition without an upcall to Constraint.

If your constraints need extra tables, give them in a list in _extra_tables.

For the legacy x_search with keywords, define a _keyword attribute containing the name of the parameter that should generate such a constraint. When pickung up such keywords, sequence values will in general be unpacked and turned into sequences of constraints. Constraints that want to the all arguments in the constructor can set takes_sequence to True.

Attributes Summary

takes_sequence

Methods Summary

get_search_condition(service)

Formats this constraint to an ADQL fragment.

Attributes Documentation

takes_sequence = False

Methods Documentation

get_search_condition(service)

Formats this constraint to an ADQL fragment.

This takes the service the constraint is being executed on as an argument because constraints may be written differently depending on the service’s features or refuse to run altogether.

Parameters:

servicedal.tap.TAPService

The RegTAP service the query is supposed to be run on (that is relevant because we adapt to the features available on given services).

Returns:

str

A string ready for inclusion into a WHERE clause.