All,
OK, so I've been working on defining a wrapper class, TableDefinition,
which would wrap the functionality of the Table proto buffer message
class. This wrapper class is used to remove the old .frm file
dependencies and allow the storage engine discovery methods to make use
of the proto buffer framework.
I would like to get suggestions on how to proceed from the point I am
currently at. To see the code in action, feel free to pull the
following branch:
lp:~jaypipes/drizzle/proto-definitions
In the drizzled/serialize/ directory, you will find a number of source
files:
table.proto
field.proto
index.proto
storage_engine.proto
foreign_key_constraint.proto
table_definition.h
table_definition.cc
test_table_definition.cc
To compile the proto files and test program, do the following from that
directory:
protoc --cpp_out=. table.proto
protoc --cpp_out=. storage_engine.proto
protoc --cpp_out=. foreign_key_constraint.proto
protoc --cpp_out=. index.proto
protoc --cpp_out=. field.proto
g++ -c table_definition.cc \
table.pb.cc \
field.pb.cc \
index.pb.cc \
storage_engine.pb.cc \
foreign_key_constraint.pb.cc
g++ -o test_table_definition test_table_definition.cc \
table_definition.o \
field.pb.o \
table.pb.o \
index.pb.o \
storage_engine.pb.o \
foreign_key_constraint.pb.o
The Serialize::TableDefinition class (defined in
drizzled/serialize/table_definition.h/.cc) is the wrapper class which
encapsulates the Serialize::Table proto buffer message class produced by
the protoc compiler. It has setters and getters such as the following:
/**
* Set the table's storage engine name
*/
inline void set_engine_name(const std::string& name) {
StorageEngine* engine= message.mutable_engine();
engine->set_name(name);
}
/**
* Returns the type of table that this is
*/
inline const Table::TableType get_type() const {
return message.type();
}
/**
* Returns a <strong>string</strong> representation
* of the value of the option of the supplied name, or
* NULL pointer if not found.
*/
const std::string* get_option_value(const char* name) const;
const std::string* get_option_value(const std::string& name) const;
/**
* Sets a table option value based on a supplied key and value
*/
void set_option_value(const char* name, const char* value);
void set_option_value(const std::string& name, const std::string& value);
/**
* Return the number of table options set by this table
*/
inline const uint32_t num_options() {
return (uint32_t) message.option_size();
}
My question is this:
Should I continue to add methods to the Serialize::TableDefinition class
which encapsulate things such as a Serialize::Field proto buffer message
class? Or, conversely, should I create a separate
Serialize::FieldDefinition class which has the field-specific functionality?
In other words, should the TableDefinition class be the single
all-access API point for readers of table, field, index, and constraint
information? Or should there be separate readers for field info, index
info, etc?
At this point, I am leaning towards TableDefinition being the single API
class for reading and writing information about a table, but I am open
to suggestions.
Your thoughts are appreciated.
Cheers,
Jay
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
