Using custom struct that models hana sequence

[neel]

I've a custom tuple like class that models, hana Comparable, Foldable, and Iterable. I want to use that instead of using tuple. Do I need to implement any other concept if I want only index based access ? What do I need to do to tell ozo to use that class instead of using tuple ?

[thed636]

Hi Neel.

Could you please clarify using a class instead of a tuple for what case? For a data row representation or a composite type representation or something else?

[neel]

This is what I am doing currently. I have a fields namespace to specify all column names that will be used in where clauses in the query.

namespace fields{
    struct field_name: some_template<int>{};
    // ...
}

Based on this I am designing a fieldset type

fieldset<fields::id, fields::name, ...> fs;
fs[fields::id::value] = 10;
fs[fields::name::value] = "Neel"

While generating the where clauses of the of the sql; query I am using this class and accessing the attributes. This saves me from writting too many getters, setters and member variables to hold the values for the where clause like the following example.

struct fetch: basic_query<fetch, row_type>, fieldset<fields::id>{
    void operator()(){
       const auto sql = "select name from table_name where id = "_SQL + cfield(fields::id::value);
       query(sql);
    }
    // ... resolve function
}

So far I am using BOOST_HANA_ADAPT_STRUCT to adapt the struct to hold the rows. But the fieldset type if already tuple like. I can also perform fs<0>() etc.. So If I am able to use that as rowset then it saves me from designing and adapting a resulting row for each select query.

If all selects for a single table uses the same row schema then the benefit is negligible. However If there are different select queries on the same table selecting varying combinations of columns then its painful and laborious to write a different struct for all the queries. std::tuple only provides indexed access. with my fieldset I can have both indexed as well as tagged access.

[thed636]

Well, looks like for your case it is better to handle query result as ozo::result and process it with ozo::recv. Both of them I've mentioned in #269 with appropriate links. So, in this case, e.g. you may use boost::hana::pair as a description of a field and construct the desirable set of fields with boost::hana::map. And, in this case, it is possible to iterate through the result rows and process every row value using the map items.

In pseudo-code it will look like this:

namespace fields {
constexpr auto field1 = boost::hana::make_pair("field1", boost::hana::type_c<int>);
constexpr auto field2 = boost::hana::make_pair("field2", boost::hana::type_c<std::string>);
constexpr auto field3 = boost::hana::make_pair("field3", boost::hana::type_c<std::string>);
}

//...

ozo::result res;
ozo::request(conn, query, std::ref(res), yield);
for(auto& row: res) {
    auto row_map = instantiate_row(field1, field3); // some stuff to convert pair of hana::string, hana::type to pair of hana::string and typed object
    boost::hana::for_each(boost::hana::keys(row_map), [&](auto key) {
        ozo::recv(row.at(key.c_str()), conn.oid_map(),  row_map[key]);
    });
};

[neel]

@thed636 I could have started in that way. But my objective was to keep ozo untouched. Instead make the data struct workable with it.

However its working now after modeling the Struct and Searchable concept. With this I no longer need to adapt structs. Also I do not need to have different structs different select queries.