Repository navigation
Releases: osprey-dcs/dp-desktop-app
Release list
rel-1.16.0
dp-desktop-app 1.16.0 Release Notes
Changes since rel-1.15.0. This repo is the JavaFX desktop GUI for the MLDP archive; it consumes
the gRPC API defined in dp-grpc 1.16.0 and implemented in dp-service 1.16.0, and the three repos
are tagged in lockstep. Several changes here exist because that API changed underneath the app —
those sections name the upstream ticket.
Two things that were true of every previous release are no longer true, and both are easy to
miss because nothing errors:
- the application no longer runs only in demonstration mode, and
- the demo database is no longer wiped at launch.
Read Upgrading from 1.15.0 before installing.
Contents
- Upgrading from 1.15.0
- Remote gRPC targets (#4)
- Query API V2, and query support for the new metadata APIs (#39)
- Annotation API modernization (#42)
- Sample status generation (#37, #38)
- Machine configuration authoring (#27, #36)
- PV metadata authoring (#18)
- Column metadata replaces request-level metadata (#17)
- Test coverage and CI (#29)
- Build and release infrastructure (#21)
Upgrading from 1.15.0
- Expect a populated demo database on first launch. Previous releases dropped
dp-demoat
startup, so every session began empty. This one does not, and a 1.15.0 database is left in
place.Tools → Delete Demo Dataclears it on request. If you were relying on the launch
drop to reset state between demos, that is now an explicit action. - Nothing needs configuring to keep the old behavior. Demo mode is the default, and an
absent or unrecognizedmodevalue resolves to demo — never to deployment. Launching with no
flags behaves as 1.15.0 did, apart from the database persistence above. - To point at a real deployment, set the mode and the connect strings. Setting only the
mode connects tolocalhoston the default ports. See
Remote gRPC targets. - Rebuild against dp-grpc and dp-service
rel-1.16.0. This release does not compile against
1.15.0 of either; the Annotation API reshaping in dp-grpc #132 is the bulk of it. Both are
resolved from the local Maven repository rather than a package registry, so install them first. - If you scripted
mvn javafx:run -Ddp.DpDesktopApp.mode=..., it does not work. The plugin
forks a JVM that does not inherit Maven's system properties, so that launch silently starts in
demo mode. Use--mode=deploymentinstead, which works on every launch path.
Remote gRPC targets (#4)
The application previously ran only in demonstration mode, with the MLDP services hosted in-process
alongside the GUI. It now also runs against already-running remote services, selected by a
mode setting:
demo(the default) — starts the self-contained in-process service ecosystem backed by the
localdp-demoMongoDB database. Unchanged from 1.15.0.deployment— connects to the four services at their configured connect strings, and
never constructs a MongoDB client at all.
Deployment mode deliberately writes no PV time-series data and authors no curated metadata for
this release. Ingestion (Ingest → Generate, Ingest → Import), metadata authoring
(Metadata → PV, Metadata → Machine Configuration), Explore → Data Events and
Tools → Delete Demo Data are all disabled; the Explore views are enabled at launch rather than
after an ingestion, since a real archive already has data to browse. It is not a read-only
mode: dataset save, annotation save and export within the Explore views remain available — they
are the analysis workflow, and they write annotation records rather than archive data.
Re-enabling import and metadata authoring against a live archive is deferred to a follow-on.
Selecting the mode
Prefer the --mode argument, which works on every launch path:
java -jar dp-desktop-app-1.16.0-shaded.jar --mode=deployment
mvn javafx:run -Djavafx.args=--mode=deployment
-Ddp.DpDesktopApp.mode=deployment also works on the shaded jar, as does a deployment
application.yml selected with DP.CONFIG=<file>. It does not work with mvn javafx:run:
the plugin forks a JVM that does not inherit Maven's system properties, so that combination
silently launches in demo mode. An explicit -D wins over --mode, so a launcher script that
always appends --mode=demo cannot override what an operator set deliberately.
An absent or unrecognized mode value resolves to demo. That direction is deliberate: a
misspelling must not become a connection attempt against production.
Configuring the targets
Four connect strings, each environment-overridable, following dp-service's convention:
| Key | Environment variable | Default |
|---|---|---|
GrpcClient.ingestionConnectString |
DP_GRPC_CLIENT_INGESTION_CONNECT_STRING |
localhost:50051 |
GrpcClient.queryConnectString |
DP_GRPC_CLIENT_QUERY_CONNECT_STRING |
localhost:50052 |
GrpcClient.annotationConnectString |
DP_GRPC_CLIENT_ANNOTATION_CONNECT_STRING |
localhost:50053 |
GrpcClient.ingestionStreamConnectString |
DP_GRPC_CLIENT_INGESTION_STREAM_CONNECT_STRING |
localhost:50054 |
Precedence is -Ddp.<key> > environment variable > the configuration file's default. The status
bar, window title and startup log all name the query target in deployment mode, so "which
archive am I pointed at" is answerable from the UI.
BEHAVIOR CHANGE: the demo database is no longer dropped at launch
Previous releases dropped dp-demo on every startup, so demo data never survived a restart — the
README said so, and that statement is now obsolete. This is the first release in which a demo
session starts with the previous session's providers, buckets, sample statuses and metadata still
present. Tools → Delete Demo Data clears it on request, with a confirmation dialog naming the
database.
Two consequences worth knowing:
- The Explore menu is now enabled when the archive has data, not only when the current session
has ingested some. Otherwise a demo relaunched on a populated database would show every Explore
item disabled over hundreds of buckets. - The delete rebuilds the schema after dropping. Dropping a database destroys its indexes, and the
services still running hold collection handles bound at their own startup — without the rebuild
the session would continue against an unindexed database while every operation kept reporting
success.
Deployment mode never constructs a MongoDB client, so none of this is reachable there.
Query API V2, and query support for the new metadata APIs (#39)
#39 subsumed three earlier tickets, which were closed as not-planned rather than implemented
separately: #19 (a view for querying PV metadata), #20 (a view for the V2 query API with PV and
machine configuration metadata as search criteria) and #34 (a view for querying machine
configuration and activation metadata). All three are delivered by the work below.
The data query migrated to Query API V2
Explore → Data now issues querySamples rather than the retired V1 queryTable. Visible
differences:
- Missing values render blank rather than
N/A. V2 distinguishes "this PV had no sample at
this timestamp" from a value the decoder did not recognize; V1 could not. A blank cell now means
genuinely missing, and anything else means a decode gap. - The 1-minute query chopping is gone. The server bounds each page itself and returns a resume
token, so the client no longer guesses a window small enough to fit under the message size limit. - Results are capped at 50,000 rows, and a capped result says so rather than reporting the
count as a total. - A running query can be stopped. The Query Editor carries a Stop Query button while a
query runs. Cancellation takes effect between pages; rows already received are kept. uint64columns display as exact unsigned decimal strings. Java has no integral type that
holds the upper half, and both alternatives display a wrong value that looks right.
PVs can be selected three ways
The Query Editor's Select PVs... dialog covers the three arms of the V2 PV selector: a name
list (the default, and unchanged), a name pattern (a regex, not a glob), and metadata
criteria resolved against curated PV metadata.
One sharp edge, stated in the dialog and in the summary line: an empty metadata query is not an
error — it matches every PV in the archive. Nothing downstream complains, so an unfilled
metadata tab produces a whole-archive scan that looks like a filter. A blank pattern is refused,
because the server rejects one.
Adding to a dataset is refused for a pattern or metadata selection: a data block is a PV name list
by definition, and building one from the displayed name list would save a dataset covering PVs the
query never touched.
The README's Querying PV time-series data section
walks through the Query Editor with these controls in place.
Two optional query filters
Query Filters... adds two restrictions, both off by default, composing by intersection:
- Machine configuration activations restrict the time axis to the intervals during which
matching configurations were live. - Sample status then drops individual samples from what survives.
The sample status mode is not a polarity switch, and the difference is in the unlabeled
samples: INCLUDE returns matching ...
rel-1.15.0
Merge pull request #22 from osprey-dcs/ci/issue-21-pin-actions-by-sha ci: pin GitHub Actions to commit SHAs
rel-1.14.0
Please see the master release notes for more information.
rel-1.13.0
See the master release notes for more information.
rel-1.12.0
See the master release notes for more information.
rel-1.11.0
See the master release notes for more information.