ORM-like model implementation in CI

[eluser]bAum[/eluser]
Hi all,

I am new to CI, and I was wondering what the general approach is to implement models that represent database records in CI.

In my understanding, CI models as they are presented in the user guide, for instance, are not a representation of some database record, but rather of a whole concept (the user guide contains the example of a "blog", not of a "blog post"). And there is the fact that CI's default behavior when loading a model is to create a single instance of that model having the model's name. This also suggests that the intent is to create a model once, like some data-oriented library.

I prefer, however, the orm/activerecord approach, where a model instance represents some record of my database, which means that I'll generally deal with several instances of the same model. Yet, as far as I understand, all loaded models are part of the CI namespace, and if I load a model twice with the same name (just imagine a loop over blogposts, for each one I would load a blogpost model which I call temp), I'll get an error that I'm using a name that already exists.

This naming conflict was just an example, I'm sure that this is not the only issue I'll have to deal with. So what would people here suggest me? How would you implement this stuff in CI (well, I could create model classes not "linked" to CI, but this would somehow undermine CI)?

Many thanks.

[eluser]sophistry[/eluser]
i suggest search for ORM in the forums - there was once upon a time an ORM implementation for CI. i am not sure if it still exists. please post your findings when you have some findings.

[eluser]Jon L[/eluser]
there shouldn't be any naming conflicts, as you are able to pass a 2nd parameter when loading a model, that determines the namespace inhabited by the model.

example from my own code, I currently have 1 model called forums_model, that will represent both threads and categories (for the moment). so I instantiate 2 occurrences, and then I call a custom method "set_method" to let the model know if I'm using threads or categories. (there are some variable variables in the code, which is why I pass in categories vs threads)

Code:

$this->load->model('forums_model','categories');
        $this->categories->set_method('categories');

        $this->load->model('forums_model','threads');
        $this->threads->set_method('threads');

[eluser]bAum[/eluser]
I thought of that solution as well, but as data from a database tends to be dynamical, I would have to append the primary key of the row I'm loading into a model to the name of that model which is not very practical.

I finally implemented this stuff with my own classes (which are no CI-models). This allows for the greatest flexibility and was the easiest solution to my problem. The drawback is that I have to code the ORM stuff on my own, but it's still reasonable.

Still many thanks to both of you for your replies.

[eluser]Jon L[/eluser]
If you're still in the need for an ORM layer, I believe there are CI contributions that fill the void

EDIT: it also might not be too complicated to take an existing external ORM layer and adapt it to CI

[eluser]esra[/eluser]
Some time ago, Dready posted a db driver for PDO (PHP5 only). It might be possible to use Doctrine's ORM with CI in conjunction with this driver since Doctrine is based on PDO. It might be worth experimentation. I believe that the Kohana fork is attempting to do something similar with better layering.

There is a article on the wiki about using Propel as a model:

http://codeigniter.com/wiki/Using_Propel_as_Model/

There is a CI-specific ORM project under development:

http://ellislab.com/forums/viewthread/51495/

[eluser]Jon L[/eluser]
interesting links esra, but the one regarding propel doesn't seem to be a complete how-to (at least, glancing over it initially), and dunno if the CI-specific ORM would be stable enough

do you use either one of those ORM projects?

[eluser]esra[/eluser]
We have some Base5 extensions under development at work that will be released later. These are designed to allow CI to support different DBALs. Since most ORMs are dependent on a specific DBAL, ORM support is much easier to address.