tomkralidis on master
Create FUNDING.yml (compare)
requirements-pg.txtinclude in https://github.com/geopython/pycsw/blob/master/requirements-dev.txt#L3 ? It's tripping up non PG workflows for me. Do we need this in the dev requirements?
@tomkralidis not requiring
requirements-dev.txt is not something I thought of while implementing it. My rationale was that usually tests would be run for all backends so I was expecting all dependencies to be installed.
In order to be able to skip on
requirements-pg.txt we'd need to have some sort of conditional import of
tests/functionaltests/conftest.py. It is doable, but requires a bit of additional work.
If you just want to disable testing pg stuff when running tests, with
tox you can run
tox --env py27-sqlite --env py34-sqlite in a similar way as is done on pycsw's
.travis.yml file. You'd still need to have
requirements-pg.txt installed though...
If this is a showstopper for you, please open a ticket and assign me to it
A filter parser is a parser for the
FILTER_LANGUAGE (using the KVP parameter name) specified in the query. In CSW we typically use two different filter languages: FES and CQL. So I guess we'd need a filter parser for FES stuff and another for CQL stuff in pyfes.
A query parser is a parser for the whole query. In the FES spec, a query is composed of (again using the KVP parameter names)
SORTBY. So a query parser needs to know how to extract this stuff from the request. Also, a query parser may use more than one filter parser. This may happen for example in a hypothetical parser trying to parse a CSW
GetRecords request, where either one of FES or CQL might be used as the filter language
I guess this is rather dense... Am I making any sense to you?
pycsw.ogc.fes.fes1parses the query into an SQL where clause. pyfes would abstract that away instead into some object/thing. So then would a backend need to crawl through the pyfes object with similar work to be able to construct the relevant query in the backend's space?
parse(some_data)function that would take care of instatiating these more esoteric query and filter parser objects in the backseat and it would return the already digested fes type for the backend to process afterwards
fes_stuff = pyfes.parser.parse(my_xml_data, **additional_arguments) records = repository.perform_pyfes_query(fes_stuff)