I think what most people would do is use SQL joins to do what you are doing and select that information in one query.
Your post has an author and a category, but there's no reason the author and category have to come from their own models. Sure, you may have author and category models in place for other parts of your application, for when you read, create and update those entities. But you don't have to necessarily use them here.
I would think your post model could look something like this, depending on your table structure.
PHP Code:
public function get_data($postID)
{
$this->db->select(post.id as post_id, post.title as title, post.content as content);
$this->db->select(users.id as user_id, users.username as author);
$this->db->select(category.id as category_id, category.name as category);
$this->db->join('users','users.id = post.author');
$this->db->join('category','category.id = post.category');
$this->db->where('id', $postID);
$query = $this->db->get('post');
if ($query->num_rows() > 0)
{
return $query->result_array()[0]
}
}
Just doing that off the top of my head, so I'm sure it's missing a semicolon and/or a quote here and there, but you probably get the idea.
The way I look at it is that "post" is a view of an entity with attributes. Some of those attributes may come from other tables, but that's ok. Your models don't have to be exact representations of database tables. You can write a function that returns the view of a post that you need without overthinking it and embedding models within models.
