openSUSE:Build Service Future Searches
Query by XPath vs by URL params
Given the following example model (simplified MySQL):
CREATE TABLE `architectures` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `selectable` tinyint(1) DEFAULT '0', PRIMARY KEY (`id`), );
It is assumed that there is a correspoding Ruby model and controller with the actions 'index', 'show' and 'update'. For XPath usage, the following XML representation is assumed:
<?xml version="1.0" encoding="UTF-8"?> <architecture name="x86_64"> <selectable>true</selectable> <enabled>true</enabled> </architecture>
Current state of OBS-2.x
Possible requests
1: GET /architecture&match="[@name=\"x86_64\" or selectable]" 2: GET /architecture&match="[$COMPLEX_PAGINATION and position()=$STH]"
Advantages
- XPath is really powerful!
Disadvantages
- Needs an XPath engine on the server (and possibly client) side
- Engine should cache parsed queries to be fast (needs MEM)
- XPath query validation needed
- Hierarchical representation of 'arch' table needed:
- Needs precise knowledge about structure to query
- Changes are troublesome
- JSON support needs custom XPath engine
- XPath is complex (i.e. hard to 'curl')
- Likely more quoting and escaping than for URL params (only 'values' have to be URL-encoded)
Wanted state (In a galaxy far far away)
Possible requests
1: GET /architectures&count=20&page=2 <- listing of archs (20-39) 2: GET /architectures&name=x86_64 <- index over 'name' wanted 3: GET /architectures&selectable=true
Advantages
- Rails allows to marshall table row(s) into XML or JSON (needs views)
- This is what everyone does (may be less of an argument)
- Rails de-marshalls and validates against table schema (no code to maintain!)
- Pagination params 'count' and 'page' map perfectly to SQL's LIMIT_BY (fast!!!)
Disadvantages
- XPath's 'or' has to be emulated via two requests (2,3) or param scheme like:
GET /architectures&name=x86_64&name=i586&selectable=true
For XPath "(name = 'x86_64' or name = 'i586) and selectable = 'true'"