- Imagine we want to select employees from a table.
You'd write a select statement like this.
I'm gonna select the employee id, the name, the salary,
and the region from the employees_temp table.
Straightforward enough.
Obviously you could do something much more complicated,
but that's a good starting point.
Right, so we have a very handy function.
We've already seen this.
In the PooledConn structure,
there's a handy method called query_map.
When you call query_map,
you pass in a select statement, SELECT * from employees,
and it'll come back with a result set.
You've also passed in a closure.
Closure, like a map function,
and it'll say for each row in the result set,
this is how I'd like you to convert it into something else.
So instead of getting back just a group of rows,
you get back a group of objects
which have been constructed from those rows.
Okay, so that's really handy.
So let's see what the code looks like in our demo.
We can look at the main function
and then we'll have a look at select_employees.
So here's my code.
I've reset the main function,
the main code to be exactly the same as before.
So in main, basically everything is still uncommented.
And in fact, it can remain uncommented
because this is the last demo that we're gonna run.
We've seen how to get a connection
and how to create a temporary table.
We've seen how to insert employees
using that handy prams macro.
And now we're gonna see how to select employees
on that connection.
And that function is gonna return back a vector
of fully fledged employee structures.
Remember the employee type, an employee has a name
and an ID and a salary and region.
It's gonna construct a function basically
which will say give me an id
and a name and a salary and a region
and I will give you back an employee containing that data.
Okay, so bearing that in mind,
let's go back into our main code
and let's have a look at this function.
It'll return back a vector of employees,
which we then output.
It iterates with the vector of employees
and outputs each employee.
Remember that the employee structure
supports default formatting.
We use curly brackets like that.
It basically looks on your employee type.
It looks for implementation of the display trade
and we have it.
Our employee does indeed implement display
and it outputs just the details of the employee,
the id, the name, the salary, and the region.
So we're looking in a good shape here.
Let's just have a look at the code
to actually do the select.
Right, it's very elegant.
So SELECT form the employees table,
select the employee_id
and the name and the salary and the region.
Okay, so we've got four employees in our database table.
So for each row that comes back in the result set,
it'll automatically invoke this closure
with the columns for that row.
Okay, so the first row, that was me, Andy,
id one, salary 25K, and a region of Wales.
So this here is a tuple that contains the id,
the name, the salary, and the region.
And all I need to do is basically create
from that data a new employee,
okay, using the employee new function,
that will create an employee object
for the first row in the result set.
And then for the second row,
it'll call this closure again
to map that row into an employee object
and it collects them together into a vector of employees
and that's what gets returned back.
Back in main, the vector of employees
that comes back from that function
are then displayed on the screen.
So all being well, this should be
the high point of the demo if it works.
So let's do a cargo run.
And it has worked.
I knew it was gonna work, to be honest.
I'd already tried it beforehand.
So it had from the top,
it had got a connection to my containerized database,
created a temporary table employees_temp,
inserted four rows into the table,
and then selected the rows back again,
give me back a bunch of model objects,
employees, which I then display on the screen.
And if it didn't already, that is me,
my wife, my daughter, and my son.
A nice way to finish off.