summaryrefslogtreecommitdiffstats
path: root/funtools/notes/view.notes
diff options
context:
space:
mode:
Diffstat (limited to 'funtools/notes/view.notes')
-rw-r--r--funtools/notes/view.notes261
1 files changed, 261 insertions, 0 deletions
diff --git a/funtools/notes/view.notes b/funtools/notes/view.notes
new file mode 100644
index 0000000..bd9db20
--- /dev/null
+++ b/funtools/notes/view.notes
@@ -0,0 +1,261 @@
+Views:
+
+We can implement views as pseudo files that actually refer to a row in a
+data base containing column, filter, and format specifiers for that view.
+
+To create a view:
+
+ funview -p "format" -r "filter" -c "columns" view file
+
+This will make an entry into a data base having the form:
+
+ view file columns filter format
+ ---- ----------- ----------- ----------- --------------
+
+Data base name will be the first one found:
+
+1. getenv("FUN_VIEWBASE")
+2. ./.funtools.vu
+3. ~/.funtools.vu
+
+For example:
+
+ funview -p "I=%3d" -r "cir 512 512 .1" -c "x y pha pi" myview snr.ev
+
+adds to database:
+
+ view file columns filter format
+ ---- ----------- ----------- ----------- --------------
+ myview snr.ev x y pha pi cir 512 512 .1 I=%.3d
+
+Also:
+
+ funview -d view # delete view from database
+ funview -l # list views
+
+Of course, you can edit the database file directly (but does this avoid
+some needed checking?) ... and we might also have a GUI ...
+
+You then use the view id instead of a file in any funtools program,
+prefixed by v:, i.e.
+
+ fundisp v:myview
+ funtable v:myview foo.fits
+
+The first command will run fundisp on the associated file, but using
+the specified filter, column, and format spec. The second runs funtable,
+which has no need of the print format but still utilizes the filter
+and column specifiers.
+
+You can override any of the three view specifiers explicitly:
+
+ fundisp v:myview'[cir 400 400 1]'
+
+uses the view format and column spec, but overrides the filter, while:
+
+ fundisp -f "I=%5d" v:myview'[cir 400 400 1]' "x y time"
+
+overrides everything but the file name ... probably useless but at
+least consistent.
+
+The syntax of a view should support templates, so that the view filter,
+columns, and format parameters can be used with multiple files.
+
+For example:
+
+ funview -p "I=%3d" -r "cir 512 512 .1" -c "x y pha pi" myview "*.ev"
+
+adds to data base:
+
+ view file columns filter format
+ ---- ----------- ----------- ----------- --------------
+ myview *.ev x y pha pi cir 512 512 .1 I=%.3d
+
+You then explicitly use a template view for a file that matches the template
+by specifying the actual filename instead of the view:
+
+ fundisp v:foo.ev
+
+Since foo.ev matches the *.ev template, this will use the myview
+columns, filter, and format on the foo.ev data file.
+
+Note possible conflict if a file name matches a view but ... we can
+avoid this to some extent by not allowing view names to contain ".",
+":", "/" (same sort of restriction in xpa).
+
+A view GUI can have a selectable option to tell funtools programs
+always to assume a file is a view, even if v: is not prepended. This means
+that, if you start the GUI and select the "auto view" switch, then:
+
+ fundisp v:myview
+and
+ fundisp myview
+
+will be handled identically. Without the GUI running, the v: prefix will
+be required.
+
+There should be a way to specify which view to use for a given file:
+
+ fundisp v(fi3):foo.fits
+
+means use view fi3 on file foo.fits
+
+ fundisp v(reg1,col2):foo.fits
+
+means use views reg1 and col2 (in that order) on file foo.fits.
+
+Wild idea: we can implement a join of files as a view (just like the
+big boy databases). I think we get this for free if FunOpen just
+opens a pipe: pseudo file (which is implemented and might actually
+work) instead of a disk file.
+
+Example: we define a view called "myjoin" to be:
+
+ view file ...
+ ---- ----------- ...
+ myjoin "funjoin -j1 key -j2 key2 cat1.fits cat2.fits" ...
+
+where the implied output arg is stdout and then we can execute:
+
+ fundisp v:myjoin
+
+and get the joined result. View filters and columns would be applied to the
+output and it all just might work ...
+
+Good points:
+
+Explicit specification of a pseudo-file "v:[viewid]" is unambiguous
+and alleviates the need to rely on a separate process to prevent
+accident use of a view. If you don't want to use the view, just don't
+specify it.
+
+Easy flexibility for overriding view parameters.
+
+Support for file templates allows default setups of filter, column,
+and formats (can even use "*" as the file for a global setup).
+
+Uses standard funtools file type paradigm (socket:, pipe:, shm: etc).
+
+If we can implement arbitrary commands as a view file type via pipe:
+(particularly funjoin), then our views will be similar (superset?) to
+SQL views (see below).
+
+Bad points:
+
+The original idea of changing getenv would have made extensions to the
+list of view parameters automatic. We now have to implement each
+access of a view parameter explicitly, as opposed to having getenv do
+it automatically. Actually, this is a two-edged sword: it also could
+be a bad thing that each and every getenv would look for a global value.
+
+Design:
+
+I. FunOpen("v:id", ....)
+
+To process a view file spec inside FunOpen():
+
+1. Look for view file, either in default (~/.funtools.views) or
+pointed to by FUN_VIEWFILE. If it does not exist, return ERROR.
+
+2. If filespec contains a directory character ("/") go to 4.
+
+3. ID or simple file: Strip off and save filter spec. Look for ID
+name. If not found, go to 4. If found, replace input name with FILE
+name. If no filter spec is specified, use FILTER, otherwise use
+(override) filter spec. Save column spec for later use by
+FunColumnActivate.
+
+4. Pathname or Simple file: Try to match file spec again template
+FILEs. If found, replace input name with FILE name. If no filter spec
+is specified, use FILTER, otherwise use (override) filter spec. Save
+column spec for later use by FunColumnActivate.
+
+II. FunColumnActivate(fun, columns, plist)
+
+1. If columns != NULL, use columns (might be override).
+
+2. If columns == NULL and fun->view_columns, use it.
+
+3. If columns == NULL and !fun->view_columns, just return.
+
+-----------------------------------------------------------------------------
+
+ Views in SQL
+
+See: http://www.cs.unibo.it/~ciaccia/COURSES/RESOURCES/SQLTutorial/sqlch5.htm
+
+5.2 VIEWS. (Virtual Tables and Data Security)
+
+A View, as we will see, is a definition for a "virtual table" (virtual
+because there is no permanent allocation of storage space) which is
+assembled at reference time from selected rows and/or columns of one
+or more real tables.
+
+A view may be queried in exactly the same way as a real table.
+
+Views are useful for two main reasons:
+
+1) they enable users to see data, from a generalised database design, in the form most convenient for their needs.
+
+2) they may be employed as a security mechanism for restricting user access to specific tables columns and/or rows.
+
+The statement used to create a view has the following general form:
+
+CREATE VIEW view-name [( column-list )]
+
+AS SELECT column-list
+
+FROM table-list
+
+WHERE conditional-expression ;
+
+You can display the specification of the views you have created using
+the help statement whose general syntax is as follows:
+
+help view view_name {,view_name}
+
+When a view is no longer required it may be dropped from the database
+with the DROP statement:
+
+DROP VIEW table-name ;
+
+5.2.1 Views Designed to Simplify Queries.
+
+As we noted with Example 4.5.4, there are no direct flights from
+Heathrow (HROW) to Brussels (BRUS). To simplify the query required to
+list the departure times of interconnecting flights we will specify a
+view called Brussels-Link.
+
+CREATE VIEW Brussels_Link
+
+AS SELECT DISTINCT B.FlightNo,B.FromAirport,
+
+B.DepTime, B.ArrTime
+
+FROM Flight A, Flight B
+
+WHERE A.FromAirport = 'HROW'
+
+AND A.ToAirport = B.FromAirport
+
+AND B.ToAirport = 'BRUS' ;
+
+Example 5.2.1 - List the FlightNo's, Airport's, Departure and Arrival
+times for flights from 1500 which link Heathrow with Brussels.
+
+SELECT FromAirport, FlightNo, DepTime, ArrTime
+
+FROM Brussels_Link
+
+WHERE DepTime >= '15:00';
+
+Result:
+
+fromai flightn deptime arrtime
+
+BIRM BD655 15:00 17:05
+BIRM BD657 17:30 19:35
+BIRM BD659 18:25 20:30
+
+
+