Skip to content

Say the generator is staged, because it is #51

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
estebanzimanyi merged 1 commit into from
Aug 31, 2026
Merged

Say the generator is staged, because it is #51

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 10 additions & 5 deletions GENERATION.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,15 +11,20 @@ binding owns its generator in its own repo. The source of truth is the catalog
## MobilitySpark is a consumer binding

MobilitySpark binds the **JMEOS jar** (the JVM FFI projection of the catalog), not MEOS-API
directly. Its generator is the shared **`tools/codegen_jvm.py --engine spark`**, the single
generator vendored identically by every JVM binding (MobilitySpark, MobilityFlink,
MobilityKafka). The `spark` engine delegates verbatim to the sibling
directly. Its generator is the shared **`tools/codegen_jvm.py --engine spark`**, which **JMEOS
owns** and this repository STAGES: `tools/codegen_jvm.py` and `tools/codegen_spark_udfs.py` are
gitignored here, copied in by the refresh chain and by CI from the JMEOS checkout, exactly as the
catalog is. Every symbol the generator emits is a call into the `functions.GeneratedFunctions`
that jar carries, so the generator and the surface it binds are one unit: a copy left in this tree
goes stale the moment that surface folds an out-parameter or widens a return. MobilityFlink and
MobilityKafka stage the same two files from the same place. The `spark` engine delegates verbatim
to the sibling
**`tools/codegen_spark_udfs.py`** (which mirrors the JMEOS `FunctionsGenerator`): it reads the
JMEOS surface and the catalog's `@sqlfn` names and emits the Spark UDF registration layer,
organized **by `@ingroup` group** (one unit per group, the same structure as the reference
manual). Every emitted `register()` is preceded by the per-thread MEOS-init guard, enforced at
build time. Sharing one generator across the JVM bindings is what keeps the surface from
drifting between engines.
build time. One generator with one home is what keeps the surface from drifting between engines;
three copies of it drifted by 202 lines before JMEOS took ownership.

## Inputs

Expand Down
11 changes: 7 additions & 4 deletions pom.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,10 +47,13 @@

<build>
<plugins>
<!-- Generate the whole UDF surface from the vendored MEOS-API catalog at
build time (North Star: bindings are GENERATED from MEOS, never hand
written). codegen_jvm.py is the single generator shared by every JVM
binding; the spark engine delegates to codegen_spark_udfs.py so the
<!-- Generate the whole UDF surface from the MEOS-API catalog at build
time (North Star: bindings are GENERATED from MEOS, never hand
written). Both the catalog and the generator are STAGED into tools/
and gitignored, never committed: the catalog is derived from
MobilityDB master by the provision-meos action, and codegen_jvm.py
with its codegen_spark_udfs.py sibling is copied in from JMEOS, which
owns them. The spark engine delegates to codegen_spark_udfs.py so the
emitted surface is identical to that generator's. It reads the
org.jmeos:meos jar's actual symbols so it never emits a call to an
absent/mismatched JMEOS method. -->
Expand Down
Loading