1. boost::rdb Various proposal for a high-level user interface

2. Motivation ● Having a core RDB library is needed... – (... but it’s not sufficent) ● What user interface do we want ? – Should the RDB nature be explicit ? – Should the SQL query be explicit strings ? – How to interface with user types ? ● Then again, what about some EDSL ?

3. Proposal #0 – Database Schema ● Motivation: – Builds a C++ representation of a DB schema ● Principles: – Fields = name + value type + string representation – A schema is a static collection of such fields ● Design: – A schema = fusion::map – Boost.Preprocessor to the rescue

4. Proposal #0 – Database Schema #include BOOST_RDB_REGISTER_FIELD(age,int) BOOST_RDB_REGISTER_FIELD(id,int) BOOST_RDB_REGISTER_NAMED_FIELD(name,std::string,"complete_name") int main() { // some rdb::core call to DB connection connection db("some.db.url","login","passwd"); // Here is some DB schema definition typedef BOOST_RDB_TABLE( (id)(name)(age) ) table_t; table_t t("employees",db); // Here is a result set definition typedef BOOST_RDB_RESULT_SET( (age)(name) ) result_t; result_t rows; //.... More to come later }

5. Proposal #1 – SQL DSL ● Motivation: – Helps SQL user writes correct SQL statement ● Principles: – Compilation ensures SQL is well formed – Send a string to the RDB core ● Design: – Provide types for building DB schema – Reproduce SQL grammar with proto

6. Proposal #1 – SQL DSL // Same code than before int main() { connection db("some.db.url","login","passwd"); BOOST_RDB_TABLE((id)(name)(age)) employee("employee",db); BOOST_RDB_RESULT_SET((age)(name)) rows; rows = select(age,name).from(employee).where( age > 45 && name ~= "Dil%" ); // Some random access if( !r.empty() ) cout << r[0][name] << " is " << r[0][age] << " years old." << endl; // Maybe some iterators too ? }

7. Proposal #2 – Request API ● Motivation: – Shields the user from writing SQL ● Principles: – Use filters like predicates to rebuild the SQL – Operator overloads for JOIN, etc... ● Design: – Use operator overloading to build the query – Proto helps rebuilding the SQL statement

8. Proposal #2 – Request API // Same code than before int main() { connection db("some.db.url","login","passwd"); BOOST_RDB_TABLE((id)(name)(age)) employee("employee",db); BOOST_RDB_RESULT_SET((age)(name)) rows; rows = employee(age,name)[ (age > 45) && name ~= "Dil%" ]; // Some random access if( !r.empty() ) cout << r[0][name] << " is " << r[0][age] << " years old." << endl; // Maybe some iterators too ? }

9. Proposal #3 – DB as Archive ● Motivation: – Solves the data retrieval using Boost.Serialization ● Principles: – Performs transaction with Proposal #1 or #2 – Use serialization to dump results into w/e container ● Design: – Defines a db_{i/o}archive type – result_set supports serialization

10. Proposal #3 – DB as archive // Same code than before int main() { connection db("some.db.url","login","passwd"); BOOST_RDB_TABLE((id)(name)(age)) employee("employee",db); vector > data; result_set rows; rows = employee(age,name)[ (age > 45) && name ~= "Dil%" ]; rows >> datas; }

11. Conclusion ● We still have choices: – Each proposal can live its own life – Maybe we can just have any of those and let user choose ● Separation of concern: – H-L user interface can be designed without waiting for the core – They can also be developed w/e the core API changes or not