4ab66de0ae
The immediate motivation for introducing frozen_mutation is inability to deserialize current "mutation" object, which needs schema reference at the time it's constructed. It needs schema to initialize its internal maps with proper key comparators, which depend on schema. frozen_mutation is an immutable, compact form of a mutation. It doesn't use complex in-memory strucutres, data is stored in a linear buffer. In case of frozen_mutation schema needs to be supplied only at the time mutation partition is visited. Therefore it can be trivially deserialized without schema.
39 lines
1.2 KiB
C++
39 lines
1.2 KiB
C++
/*
|
|
* Copyright (C) 2015 Cloudius Systems, Ltd.
|
|
*/
|
|
|
|
#pragma once
|
|
|
|
#include "atomic_cell.hh"
|
|
#include "keys.hh"
|
|
#include "mutation.hh"
|
|
#include "mutation_partition_view.hh"
|
|
|
|
|
|
// Immutable, compact form of mutation.
|
|
//
|
|
// This form is primarily destined to be sent over the network channel.
|
|
// Regular mutation can't be deserialized because its complex data structures
|
|
// need schema reference at the time object is constructed. We can't lookup
|
|
// schema before we deserialize column family ID. Another problem is that even
|
|
// if we had the ID somehow, low level RPC layer doesn't know how to lookup
|
|
// the schema. Data can be wrapped in frozen_mutation without schema
|
|
// information, the schema is only needed to access some of the fields.
|
|
//
|
|
class frozen_mutation final {
|
|
private:
|
|
bytes _bytes;
|
|
frozen_mutation(bytes&& b);
|
|
public:
|
|
static frozen_mutation from_bytes(bytes representation);
|
|
frozen_mutation(const mutation& m);
|
|
|
|
bytes_view representation() const { return _bytes; }
|
|
utils::UUID column_family_id() const;
|
|
partition_key_view key(const schema& s) const;
|
|
mutation_partition_view partition() const;
|
|
mutation unfreeze(schema_ptr s) const;
|
|
};
|
|
|
|
frozen_mutation freeze(const mutation& m);
|