Skip to content
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.

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

Engine and query serialization #628

Merged
merged 7 commits into from
Dec 31, 2024
Merged

Conversation

V0ldek
Copy link
Member

@V0ldek V0ldek commented Dec 30, 2024

Short description

Implemented serde::Serialize and serde::Deserialize for MainEngine in rsonpath-lib, and JsonPathQuery in rsonpath-syntax with all of its constituent substructs.

The serde dependency is guarded behind an optional feature.

Issue

Resolves: #624
Obsoletes: #625

Checklist

All of these should be ticked off before you submit the PR.

  • I ran just verify locally and it succeeded.
  • Issue was given go ahead and is linked above OR I have included justification for a minor change.
  • Unit tests for my changes are included OR no functionality was changed.

Implemented `serde::Serialize` and `serde::Deserialize`
for `MainEngine` in rsonpath-lib, and `JsonPathQuery`
in rsonpath-syntax with all of its constituent substructs.
The `serde` dependency is guarded behind an optional feature.

To properly proptest this feature `rsonpath-lib` needs access
to the arbitrary query generation from `rsonpath-syntax`.
The cleanest way to do this is to extract the logic to a separate
crate, giving rise to `rsonpath-syntax-proptest`.

The serialization format is not stable, as the `Automaton`
is expected to evolve. Thus, serialization includes a version
and deserialization will fail if the version disagrees.

Ref: #624
Added snapshot tests based on `insta` to both the rsonpath-syntax
and rsonpath-lib serialization features.

Ref: #624
@V0ldek V0ldek changed the title V0ldek/#624 engine serialization Engine and query serialization Dec 30, 2024
@V0ldek
Copy link
Member Author

V0ldek commented Dec 30, 2024

@azoyan Does this suit your usecase?

@azoyan
Copy link
Contributor

azoyan commented Dec 30, 2024

@azoyan Does this suit your usecase?

Yes. It is perfect.

I am completely satisfied already at the previous step, having implemented serialization for my wrapper.

But maybe it is worth asking someone else. Invite other developers to the discussion. So that in the future you do not break the binary data format if something needs to be changed.

@V0ldek
Copy link
Member Author

V0ldek commented Dec 30, 2024

The binary format will definitely be broken at some point, e.g. #117 has to change the way we represent labels internally while #154 and #156 will most likely fundamentally change the Automaton representation.

Once we hit 1.0.0 there'll be some stability guarantees, but that's a long way away with my current dev resources of "me during a weekend" lol

@V0ldek V0ldek merged commit 4b81feb into main Dec 31, 2024
50 checks passed
@V0ldek V0ldek deleted the v0ldek/#624-engine-serialization branch December 31, 2024 00:07
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.

Support serde::Serialize and serde::Deserialize for the engine
2 participants