08.0 DB Sets

DBset is the most important feature of StubbyDB. It is nothing but a data table where first row is header and other rows are actual data. Each column is separated by '|' pipe sign. There is not pipe sign expected in the starting or ending of a row. Values of first column are treated as key to identify that row.

In configuration file you need to specify dbset folder. In request-response mapping, you need to specify the name of dbset which is nothing but the file name in dbset folder.

-  request:
      url: /stubs/mix
      post: Hello ([a-zA-Z]+)!!
      method: POST
      
   dbset:
      db: Sample.txt
      key: '001'

   response:
      file: mix.txt

Sample.txt

	key	|value		|markerval
	001	|1,2		|{{TODAY}}
	1	|value	    |{{TODAY+1y-2m+3d}}

Now you can use column name as ##columnnamw## in anywhere in response body or response file.

It is a skeleton based approach. You create a response skeleton and fill it with data at run time.

Values of db and key can be dynamic.

-  request:
      url: /stubs/(admin|staff|customer|security)/([0-9]+)
      
   dbset:
      db: <% url.1 %>
      key: <% url.2 %>

   response:
      file: authentication.xml

For above example, I have created 4 dbsets: admin, staff, customer, and security. Sample data from each dbset is as below

emp_num | token
001 	 | safknf-34809n-skfnjk
002 	 | asfno0-230480932n-kjnkl
003  	 | nk002834-oknkjn-098nkjn

authentication.xml

<auth_id>##token##</auth_id>

Now if you request as localhost:7777/stubs/admin/001, it'll response <auth_id>safknf-34809n-skfnjk</auth_id>

If the url is localhost:7777/stubs/other/001, request will not match with this mapping. It'll try to match with other mappings in the file. If it matches with no mapping then it'll respond with 404.

If the url is localhost:7777/stubs/admin/004, It'll match with the above mapping. But it'll not find key value in admin dbset. It'll not try to match with further mappings in the yaml file and will respond with 404.

If you want StubbyDB to check for further mappings, specify an err attribute.

-  request:
      url: /stubs/(admin|staff|customer|security)/([0-9]+)
      
   dbset:
      db: <% url.1 %>
      key: <% url.2 %>
      err: skip

   response:
      file: authentication.xml

-  request:
      url: /stubs/(admin|staff|customer|security)/([0-9]+)
      
   dbset:
      db: prohibited_user_db
      key: <% url.2 %>
      err: skip

   response:
      strategy: random
      files: ['unauthorized.xml','deleted.xml','locked.xml']

-  request:
      url: /stubs/(admin|staff|customer|security)/[0-9]+
      
   response:
      file: user_not_found.txt 

In above example, for url localhost:7777/stubs/admin/004, StubbyDB will first try to find key value in admin dbset, if it is not found then it'll go to match next mapping. Since the request attributes are matching, it'll try to search key value in prohibited_user_db dbset. If the value is found it'll serve any random response from specified list of files. If the key is not found, it'll try to match with next mapping and the response from user_not_found.txt will be served.

If you don't want to match further mappings but you wan't to return specific response;

-  request:
      url: /stubs/(admin|staff|customer|security)/([0-9]+)
      
   dbset:
      db: <% url.1 %>
      key: <% url.2 %>
      err:
         file: fault.xml

   response:
      file: authentication.xml

Strategy

You can define strategy for dbset as well. Currently only strategy, random is supported.

-  request:
      url: /stubs/(admin|staff|customer|security)/[0-9]+
      
   dbset:
      db: authtokens
      strategy: random

   response:
      file: authentication.xml

In above example, StubbyDB will respond with random auth token.

There are more strategies in plan. So keep watching this space ... :)

See the Demo application for better understanding.