Simpler, chain-able API

[scaleupcto]

I propose we overhaul the entire tripod API and make it chainable. In doing this, we should cut down the amount of available methods, at the same time making them work across various storage types (CBD, tables, views).

For example:

$tripod->db("my_db")->cbd("users")->describe(..);
$tripod->db("my_db")->cbd("users")->describe(..)->filter(..);
$tripod->db("my_db")->cbd("users")->select(..);  
$tripod->db("my_db")->cbd("users")->distinct(..);

$tripod->db("my_db")->views("users")->describe(...);
$tripod->db("my_db")->views("users")->describe(...)->filter(...);

$tripod->db("my_db")->tables("users")->select(..)->filter(...)->offset(10)->sort(...);
$tripod->db("my_db")->tables("users")->select(..)->limit(10)->offset(10)->sort(...);
$tripod->db("my_db")->tables("users")->distinct(...);

Instead of returning arrays or graphs the api calls would return cursor-style objects (which can be iterated where appropriate) which will optimise data retrieval on very large sets (i.e. tables) without manually having to use limit and offset.

I think we could get away with a small amount of methods, something like:

describe(); // returns a graph cursor
select(); // returns a tabular cursor
distinct(); // filters the cursor to unique values
filter(); // apply a condition to a graph or tabular cursor

// specific to tabular cursors
offset();
limit();
sort();

// data sources
tables(); // you can only get tabular cursors from these - select() only
views(); cbds(); // you can get either tabular or graph cursors from these - select() or describe()

[maheshchand]

Method chaining and returning cursors should make tripod more simpler and yet powerful. This means lesser processing on data before it is actually used in app.

[lordtatty]

+1 from me.
On 12 Sep 2014 15:07, "Chris Clarke" notifications@github.com wrote:

I propose we overhaul the entire tripod API and make it chainable. In
doing this, we should cut down the amount of available methods, at the same
time making them work across various storage types (CBD, tables, views).

For example:

$tripod->db("my_db")->cbd("users")->describe(..);$tripod->db("my_db")->cbd("users")->describe(..)->filter(..);$tripod->db("my_db")->cbd("users")->select(..); $tripod->db("my_db")->cbd("users")->distinct(..);
$tripod->db("my_db")->views("users")->describe(...);$tripod->db("my_db")->views("users")->describe(...)->filter(...);
$tripod->db("my_db")->tables("users")->select(..)->filter(...)->offset(10)->sort(...);$tripod->db("my_db")->tables("users")->select(..)->limit(10)->offset(10)->sort(...);$tripod->db("my_db")->tables("users")->distinct(...);

Instead of returning arrays or graphs the api calls would return
promise-style objects (which can be iterated where appropriate) which will
optimise data retrieval on very large sets (e.g. tables) without manually
having to use limit and offset.

I think we could get away with a small amount of methods, something like:

describe() // returns a graph cursorselect() // returns a tabular cursordistinct() // filters the cursor to unique valuesfilter() // apply a condition to a graph or tabular cursor
// specific to tabular cursorsoffset()limit()sort()
tables() // you can only get tabular cursors from these - select() onlyviews(); cbds(); // you can get either tabular or graph cursors from these - select() or describe()

—
Reply to this email directly or view it on GitHub
#23.