Union deserialization behavior is confusing #86
Labels
No labels
backend
beginner-friendly
bug
build
db
endpoint
federation
http
low-priority
tests
waiting for zig 0.11
web
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: heartles/fediglam#86
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Right now, unions have the behavior where the union itself is treated as invisible, its members are dumped into its parent scope. For example, the type:
Is treated as if the parameter
foo
must be provided and exactly one ofqux
orbaz
must also be provided. So the json value{"foo": "abc", "qux": "xyz"}
would be valid and would deserialize to.{ .foo = "abc", .bar = .{ .qux = "xyz" } }
.There are a few problems with this approach:
std.json
handles unions, which is to treat its members as invisibleSo for example, the json value
{"foo": "abc", "bar": "xyz"}
would deserialize to the same value.This behavior was originally written for pagination code, which often has the following idiom:
Where the idea is that prev.value must match order_by, and the two will be compared in sql like
(id, <col>) > ($id, $value)
. This allows the user to pass parameters like (using query string syntax):?order_by=created_at&prev.id=ID&prev.created_at=DATETIME
This could be rewritten to use the
std.json
format, with some duplication, to be like:While this may seem important for parsing ActivityPub types, we will need to handle them specially without using the serialization library. This is because, while they do have defined fields in the spec, if we only used the fields in the spec we would lose any extension information.
Another issue is for the handling of some of the webpage POST calls (especially within the drive system).
There are a number of actions the user can take on a drive entry (delete, move, create subdir, edit, upload), all of which are forced to share the POST method and all of which have different parameters:
Right now these are all mapped to the same
POST /drive/:path*
endpoint.This raises some questions:
I fixed the deserialization syntax to work like std.json as of
f47c1ee751
The solution i went with for the webpge POST thing i mentioned was to put the action in the query string, then add a thing that lets the body deserialization type come from that.