Skip to content

Releases: osprey-dcs/dp-desktop-app

rel-1.16.0

Choose a tag to compare

@github-actions github-actions released this 16 Sep 21:22
7b1a378

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

  1. Expect a populated demo database on first launch. Previous releases dropped dp-demo at
    startup, so every session began empty. This one does not, and a 1.15.0 database is left in
    place. Tools → Delete Demo Data clears it on request. If you were relying on the launch
    drop to reset state between demos, that is now an explicit action.
  2. Nothing needs configuring to keep the old behavior. Demo mode is the default, and an
    absent or unrecognized mode value resolves to demo — never to deployment. Launching with no
    flags behaves as 1.15.0 did, apart from the database persistence above.
  3. To point at a real deployment, set the mode and the connect strings. Setting only the
    mode connects to localhost on the default ports. See
    Remote gRPC targets.
  4. 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.
  5. 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=deployment instead, 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
    local dp-demo MongoDB 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.
  • uint64 columns 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 ...

Read more

rel-1.15.0

Choose a tag to compare

@github-actions github-actions released this 14 Aug 18:28
dac25ab
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

Choose a tag to compare

@craigmcchesney craigmcchesney released this 06 May 21:03
fdb0049

Please see the master release notes for more information.

rel-1.13.0

Choose a tag to compare

@github-actions github-actions released this 27 Feb 21:45
b559fe9

See the master release notes for more information.

rel-1.12.0

Choose a tag to compare

@github-actions github-actions released this 13 Jan 00:10
8c4af3d

See the master release notes for more information.

rel-1.11.0

Choose a tag to compare

@craigmcchesney craigmcchesney released this 14 Sep 18:20
9341e54

See the master release notes for more information.