Resuable models

[eluser]solepixel[/eluser]
I thank Chad for this useful advice. The bottom line is extending Models that extend Model was a bit tricky and was what the OP was trying to accomplish, and although Treeda's DB structure may not have been perfect, the issue still remained. And people like me come here to read how to do it myself, and have to go through all this arguing before find the solution.

As I was reading it was saying in my head "Is this how CI people deal with issues? Change your data structure rather than addressing a problem with CI? Wow."

FYI, i'm using a base data model that handles errors, post data, get_one, get_all, defaults etc, and my need a few adjustments based on what data I need to use it with, so I'm extending Module with PageModule or AdModule, so yes, it is necessary.

[eluser]jedd[/eluser]
Hi solepixel and thanks for your comments on this old thread.

[quote author="solepixel" date="1252379636"]
And people like me come here to read how to do it myself, and have to go through all this arguing before find the solution.
[/quote]

I'd be quite distrustful of any forum where there were two messages (and only two message) in every thread - the first asking The Question, and the second providing The Solution.

I think if you seek Absolute Truth without accepting that people will argue their case, you're on the wrong foru^H^H^H^Hplanet.

As I was reading it was saying in my head "Is this how CI people deal with issues? Change your data structure rather than addressing a problem with CI? Wow."

Well, I'm probably not indicative of 'CI people'. The fact that I'm now arguing my case to you is probably revealing, in and of itself.

I'm not sure how much you know about database design - it may well be that you know much more than me (as I'm not hugely proficient in the art) -- but consider for a moment what you'd do if you looked at the stated schema, and assessed it was broken by design. Would you suggest it be rectified as the first step, and thereby removing the 'problem' as posted simply as a side-effect? The concept of 'duty of care', and all that.

It's also worth noting that judging by his comments, the original poster was cognoscente of their design's shortcomings, too.

As an academic exercise it might be nice to consider 'from this broken starting point, and assuming we have no power to change our conditions, what could we do to fix this?' - but as a pragmatic exercise it's easier to simply fix your starting conditions.

I'd also suggest that there's no apparent 'problem with CI' as far as I could / can see here.

FYI, i'm using a base data model that handles errors, post data, get_one, get_all, defaults etc, and my need a few adjustments based on what data I need to use it with, so I'm extending Module with PageModule or AdModule, so yes, it is necessary.

It's quite possible that you have the exact same problem as the poster above, or that your approach is the optimal solution to your particular conditions.

But it's hard to say for sure without a schema to pick holes in

[eluser]Treeda[/eluser]
"but as a pragmatic exercise it’s easier to simply fix your starting conditions."

Jedd i think you still didn't understood that that wasn't the exercise, seems it's worthless to discuss with you because you are not able to understand the real problem. Maybe my example was a bad example but you could show more flexibility instead of your wonderful arguing skills solving a question instead of avoiding the question.
Closing the eyes and not seeing the problem don't erase it :-)

*SCNR*

Treeda

[eluser]n0xie[/eluser]
Well jedd did solve the problem for you. It basically boils down to this: you can't wrap good code around bad design.

You could solve this kind of problem with an 'interface'. Still it doesn't matter how you build it, unless you provide us with a better 'example' for all purposes this will still be bad design.

comment_model.php

Code:

/**
* Warning: HERE BE DRAGONS!!
* don't use if you have any understanding of how relational databases work
* since this issue is void if you merge the tables and add a 'type' identifier
*/
class Comment_model extends Model {

    private $table;

    function Comment_model()
    {
        parent::Model();
    }

    /**
     *  here we offer 2 ways to access the model
     *  an 'interface' if you will
     *  although obviously real OOP interfaces
     *  do this sort of magic 'automatically'.
     *
     */

    public function get_magazine_comment($id = NULL, $limit = 1)
    {
        $this->set_table('table_magazine');
        return $this->get_comment($id, $limit);
    }

    public function get_book_comment($id = NULL, $limit = 1)
    {
        $this->set_table('table_book');
        return $this->get_comment($id, $limit);
    }

    /**
     *  Let's keep this part hidden from the rest
     */
    private function set_table($table)
    {
        $this->table = $table;
    }

    private function get_comment($id, $limit = 1)
    {
        $this->db->where('id', $id);
        $this->db->limit($limit);
        $query = $this->db->get($this->table);

        if ($query->num_rows() > 0)
        {
            return $query->result();
        }
        else
        {
            return FALSE;
        }
    }
}

Now if you want to abuse the relational database even more you could add endless amount of tables and just have to add another 'interface' function. It's KISS and DRY !

[eluser]jedd[/eluser]
[quote author="Treeda" date="1252411546"]
Closing the eyes and not seeing the problem don't erase it :-)
[/quote]

Curiously, this is the point that I have been making.

Anyway, if you bent things out of shape such that they now work, it could be argued (just not by me) that that's all that matters.