Enum ParseValue 

pub enum ParseValue {
    Null,
    Bool(bool),
    Number(f64),
    String(String),
    Array(Vec<ParseValue>),
    Object(ParseMap),
    Date(ParseDate),
    Pointer {
        class_name: String,
        object_id: String,
    },
    GeoPoint {
        latitude: f64,
        longitude: f64,
    },
    Bytes(Vec<u8>),
    File {
        name: String,
        url: Option<String>,
    },
    Polygon(Vec<(f64, f64)>),
    Relation {
        class_name: String,
    },
}

A Parse value.

The data plane stays dynamic on purpose. There is no compile-time struct per application class, because the schema does not exist at compile time. Object and Array contents are deliberately opaque.

Deliberately no PartialEq. See the module note.

Deliberately not #[non_exhaustive], either, and that is the opposite of the usual advice. non_exhaustive lets a downstream crate keep compiling when a variant is added, by forcing it to carry a wildcard arm. For this type that is precisely the wrong trade: every consumer is a total function over the value space, an encoder, a decoder, a storage transform, an equality predicate, and a wildcard arm in any of them is a silent data-loss bug waiting for the next variant. The whole premise of writing this in Rust is that forgetting a case is a compile error; non_exhaustive on this enum would make that false across exactly the crate boundary that matters.

Adding a variant here is a breaking change on purpose. ErrorCode keeps non_exhaustive, because nobody exhaustively matches sixty error codes and a new one genuinely is additive.

Variants

Null

Bool(bool)

Number(f64)

JavaScript has exactly one number type. Matching its lossiness above 2^53 is the goal, not avoiding it.

String(String)

Array(Vec<ParseValue>)

Object(ParseMap)

Date(ParseDate)

{"__type":"Date","iso":"..."}, or a bare ISO string at createdAt/updatedAt.

Pointer

{"__type":"Pointer","className":"...","objectId":"..."}

Fields

class_name: String

object_id: String

GeoPoint

{"__type":"GeoPoint","latitude":n,"longitude":n}

Fields

latitude: f64

longitude: f64

Bytes(Vec<u8>)

{"__type":"Bytes","base64":"..."}. Held decoded, because Mongo stores BSON Binary and re-encoding from a canonical byte slice is what keeps the two backends agreeing.

File

{"__type":"File","name":"...","url":"..."}. url is absent on a file pointer that has not been through expandFilesInObject, so it is optional rather than defaulted.

Fields

name: String

url: Option<String>

Polygon(Vec<(f64, f64)>)

{"__type":"Polygon","coordinates":[[lat,lng],...]}

Note the axis order: Parse’s wire form is latitude first, the reverse of GeoJSON. PolygonCoder.databaseToJSON swaps on the way out (MongoTransform.js:1362-1372), so holding it in wire order keeps that swap confined to the Mongo boundary.

Relation

{"__type":"Relation","className":"..."}

Fields

class_name: String

Implementations

impl ParseValue

pub fn to_json(&self) -> String

Serialize to the exact bytes Parse Server would emit.

Numbers go through js_number::to_ecma_string rather than any Rust float formatter, for the reasons in that module. Non-finite numbers become null, which is what JSON.stringify does; to_ecma_string alone would emit NaN, which is not valid JSON.

Trait Implementations

impl Clone for ParseValue

fn clone(&self) -> ParseValue

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for ParseValue

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.