When inserting or updating a timed event, a trigger
searches the real time events table for a position
close (within one minute) of the event time and
adds it to the event's metadata.
It shows a graphical representation of the
acquisition status of a preplot line, as
stacked bars where each bar represents the
acquisition extent of a sequence. This is
complemented by colour denoting the raw/final/
ntbp status of the sequence and by a tooltip
with the same information. Sequence bars may be
made clickable by providing a function to the
"sequence-href" property; this function should
take a sequence object and return a URL.
We try to ensure that for each sequence we have
at least FSP and LSP entries. We do this by:
* If there exists a FGSP / LGSP, we clone those as
FSP / LSP respectively.
* Otherwise, we take the first and last shots
found in the final P1 which have a preplot.
We also include log comments whenever possible and
format the azimuth a bit better.
On the backend, the events endpoint caches responses
by ETag in order to reduce the load on the database
and response times. That cache is supposed to be
invalidated with the middleware receives a notification
that the underlying data has changed. However, that
change might arrive just *after* the HTTP request,
meaning that if we let the browser do its thing we
will probably be returning stale data.
So what we do is we explicitly request a non-cached
response when we know that something has changed
because we changed it ourselves.
What we do not do is bypass the cache if we receive
a change event notification, as we assume that the
HTTP roundtrip will be more than sufficient for
the server to have invalidated (and perhaps even
refreshed) its response.
If the nav header is being received, this will
try to detect the start and end of line and create
an entry in the log.
It doesn't check whether FSP/FGSP LSP/LGSP entries
already do exist for that sequence.
Closes # 28.
If a QC has failed in the past there will be a
record of it in raw_lines, raw_shots or preplot_points.
If that QC then stopped failing, e.g., because of a
change of parameters, then the QC results would correctly
reflect the change but not the line/shot tables and
hence, the event log.
This commit hopefully takes care of that.
The database upgrade script is updated to export
also user-entered data stored in columns of tables
containing also derived data, and to re-import
everything after the upgrade.
Unlike system_imports.py and system_exports.py, which
deal with whole tables via COPY, this allows us to
export / import *either* whole tables or specific
columns only.
The data will be exported to text files containing
the selected columns + the primary key columns for
the table.
When importing, those tables for which a selection
of columns was exported must already be populated.
The import process will overwrite the data of the
non primary key columns it knows about. If whole
tables are exported, on the other hand, when
re-importing rows will be appended rather than
updated. It is the user's responsibility to make
sure that this will not cause any conflicts.
The callback has the signature (err, res) where
res is the result object from the fetch() request
and err is non-null if an error occurred and fetch()
threw.
The callback is called before res.json() has had a
chance to run it is really not recommended to
consume the body from this callback as this will cause
an error in the API action itself.
Script meant to be run by runner.sh.
It will not overwrite existing files. If a
sequence is modified after the first export,
the resulting file needs to be removed by the
user before a re-export will occur.
The idea is to eventually export on demand
when a new raw is added to final_lines.
The events endpoint will return data in the format
agreed with Multiseis if the request has an
Accept: application/vnd.seis+json
header.
Related to #12.
The reason for refactoring was to accommodate
Multiseis / client sequence exports, which will be
served by this endpoint via a specific Content-Type.
In the process, the cache has been fixed and redesigned.
Related to #12.
This is not really a substitute for proper database
design but if deemed useful it might be refactored
into a more generic caching middleware and applied
to other requests as a low-cost alternative to
database refactoring while we gain usage and
performance information.
