Skip to content

Rust IP Intelligence generator writes Float and WktString as the crates declare them - #47

Draft
jwrosewell wants to merge 3 commits into
rcfrom
feature/rust-float-and-wkt
Draft

jwrosewell wants to merge 3 commits into
rcfrom
feature/rust-float-and-wkt

Conversation

@jwrosewell

@jwrosewell jwrosewell commented Nov 8, 2026 •

Copy link
Copy Markdown
Contributor

The PropertyGenerator's Rust IP Intelligence builder writes ip-intelligence-shared/src/ip_intelligence_data.rs in 51degrees-rust. That file has been changed by hand twice since it was last generated, and the builder does not yet write either change, so the next generation would undo both. This pull request makes the builder write them, in three commits. The first can go on its own, and the second and third go together.

  1. Single published as Float (dbfd02c). The property type table gave a Single property PropertyValueType::Double, because the Rust core had no single precision type when the builder was written. The core now has PropertyValueType::Float, and 51Degrees/51degrees-rust@98a88ba declares Latitude and Longitude with it, as the IP Intelligence data model and .NET type them float. 98a88ba is on 51degrees-rust's release/dotnet-parity branch, which goes into the next Rust release. The accessor (f32) and the store getter (float) were already right, and the comment explaining the old mapping goes because it is no longer true.
  2. WKBR given as WktString (f2ca14f), changed by commit 3. Areas, the only WKBR property, was a plain String. Draft 51Degrees/51degrees-rust#345 gives it the WktString type the IP Intelligence data model names, as .NET does, and edits the generated file to match. The builder now writes AspectPropertyValue<WktString>, reads it with wkt_string, publishes PropertyValueType::WktString and imports WktString from fiftyone_pipeline_core. The C# builder already maps WKBR to WktString. A weighted WKBR keeps the weighted string list, because the Rust data base reads every weighted property as strings, and no property in the metadata is a weighted WKBR.
  3. WKBR's accessor kept as String (c4d05b4). The review of 51degrees-rust#345 kept IpIntelligenceData::areas as AspectPropertyValue<String>. Releases of the crates move only the patch number, and Cargo's SemVer guide treats a changed trait item signature as a major change, which a caller's default requirement such as "4.5.2" would take on the next cargo update. Areas is still held as a WktString, so the property type table keeps PropertyValueType::WktString for WKBR. The accessor goes back to String read by the string getter, which gives the WKT value's text, and WktString leaves the file's imports because no accessor returns it. Together, commits 2 and 3 change only the table type, and the C# builder still gives WKBR as WktString.

Merge order

  • Commit 1 matches code already merged into 51degrees-rust's release branch, so it can merge whenever this is reviewed.
  • Commits 2 and 3 publish PropertyValueType::WktString, which only 51degrees-rust#345 adds to fiftyone_pipeline_core, so they merge together and only after 51degrees-rust#345 does. The question 51degrees-rust#345 asked, whether areas() may change from String to WktString in a patch release, is settled as no, which commit 3 follows.

How it was checked

Nothing was built or run locally, because local builds on this machine are paused while disk space is short. This repository's Pull Request workflow builds the PropertyGenerator.

The generator could not be run, so its mapping was checked against the metadata instead.

  1. The IP Intelligence properties the builder reads (IPIV4Enterprise and IPIV4Lite, distinct by name, plus its Ip and IpV6 echo properties) were listed with their value types from the embedded metadata in the cached FiftyOne.MetaData 5.1.77 package, by loading the DLL in PowerShell with MetaDataService over EmbeddedResourceService. Latitude and Longitude are the only Single properties and Areas the only WKBR one.
  2. A script modelled the builder's three choices for each property (the accessor type, the store getter and the property type table entry) under three sets of rules, and compared each property in the Rust file with them.
Rules 51degrees-rust initial release (bce02be) release/dotnet-parity (217a8ed) 51degrees-rust#345 at 6f0e937 51degrees-rust#345 at 798c8a0
rc before this change 51 of 51 match 49, not Latitude or Longitude 48, not Areas, Latitude or Longitude 48, not Areas, Latitude or Longitude
With commit 1 49, not Latitude or Longitude 51 of 51 match 50, not Areas 50, not Areas
With commits 1 and 2 48, not Areas, Latitude or Longitude 50, not Areas 51 of 51 match 50, not Areas
With commits 1 to 3 48, not Areas, Latitude or Longitude 50, not Areas 50, not Areas 51 of 51 match

So the old rules give the file as first generated, commit 1 gives the Float edit, commits 1 to 3 give 51degrees-rust#345's file as it now stands, and no other property changes. 798c8a0 is 6f0e937 with release/dotnet-parity merged in and the review's changes, and its Areas is AspectPropertyValue<String> read by string with the table type WktString.

Not in this change

  • Generating the file again from metadata 5.1.77 would also add the seven GeoNameId properties the Rust file lacks (ContinentGeoNameId, CountryGeoNameId, CountyGeoNameId, RegisteredCountryGeoNameId, StateGeoNameId, StateGeoNameIdsGeographical and TownGeoNameId), which 51Degrees/51degrees-rust#226 item 2 asks for, and the links and value tables in each accessor's comment that fcd068b added. Both belong to the change that generates the file again in 51degrees-rust.
  • 51degrees-rust#226 item 1 changes how a weighted value is written (RawWeighting and Value rather than value and weight). If that changes the core type the table publishes for a weighted property, the builder's KeyValueList and its comment change with it, in a pull request of its own.
  • The Device Detection builder maps Single to f64 and Double throughout, and the Device Detection file has had no hand edit, so it is unchanged.

CI

On c4d05b4, Pull Request run 42492501817 passed. "Build PropertyGenerator" built with 0 errors and the same 4 warnings at the same lines as below, and "Build CopyrightUpdater" with no warnings. Only rc into main passed.

Earlier, on f2ca14f, Pull Request run 42482237555 passed. "Build PropertyGenerator" built with 0 errors and 4 warnings, being CS8714 at ClassBuilderBase.cs line 74, CS8618 and CS0169 on IpIntelligence._properties, and CS8603 at GeneratorBase.cs line 63. These are the same four warnings at the same lines as rc's own run on 3e68c92 (41697793840), so this change adds none. "Build CopyrightUpdater" built with no warnings, and Only rc into main passed. The workflow builds the generator but does not run it, so the table above is the check of what it writes.

The Rust IP Intelligence builder published a Single property in the property
type table as PropertyValueType::Double, because the Rust core had no single
precision type when the builder was written. The Rust core now has
PropertyValueType::Float, and 51degrees-rust declares Latitude and Longitude
with it by hand in ip-intelligence-shared/src/ip_intelligence_data.rs
(51Degrees/51degrees-rust@98a88ba), as the IP Intelligence data model and .NET
type them float. A generated file now carries the same declaration, so the
next generation does not undo that edit.

The accessor (f32) and the store getter (float) were already right. The
comment that explained the old mapping is removed, as it is no longer true.
The Rust IP Intelligence builder gave a WKBR property, which is Areas, as a
plain String read by the string getter and published as
PropertyValueType::String. 51Degrees/51degrees-rust#345 (a draft) gives Areas
the WktString type the IP Intelligence data model names, as .NET does, and
changes the generated ip_intelligence_data.rs by hand to match. This makes
the builder write the same: the accessor returns AspectPropertyValue<WktString>,
the impl reads it with wkt_string, the property type table publishes
PropertyValueType::WktString, and the file imports WktString from
fiftyone_pipeline_core. The C# builder already maps WKBR to WktString.

A weighted WKBR property keeps the weighted string list, because the Rust
data base reads every weighted property as a list of strings and no
property in the metadata is a weighted WKBR.

This needs WktString in fiftyone_pipeline_core, which comes with
51Degrees/51degrees-rust#345, so it merges only after that pull request does
and only if it keeps the WktString type.
The review of 51Degrees/51degrees-rust#345 kept IpIntelligenceData::areas
as AspectPropertyValue<String>, because releases of the crates move only
the patch number and Cargo's SemVer guide treats a changed trait item
signature as a major change. Areas is still held as a WktString, so the
property type table keeps PropertyValueType::WktString for WKBR, and the
accessor goes back to String read by the string getter, which gives the
WKT value's text. WktString leaves the file's imports, as no accessor
returns it.

The C# builder is unchanged and still gives WKBR as WktString.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant