The wikis are now using the new authentication system.
If you did not migrate your account yet, visit https://idp-portal-info.suse.com/

openSUSE:Build Service Future Searches

Jump to: navigation, search

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'"