How do you use an ORM library with traditional CI libraries?

[eluser]Devon Lambert[/eluser]
Hello CIers,

Question: How do you incorporate an existing ORM Library (Doctrine, DataMapper, RDM, etc...) into your CI project, OR future projects, while also taking into considerations libraries that have not made use of an ORM?

Example/Perfect Scenario: Let's say you wanted to make use of one of the fantastic User Authentication/Authorization libraries that have already been built by some of the senior members in the CI community, Ion Auth immediately comes to mind, it's my personal choice, but there are countless others. Ion Auth makes use of it's Models to handle your DB interactions. If you wanted to make use of an ORM library you would, in essence, have to refactor countless lines of code to make the auth library fit nicely in with your ORM setup, no?

I suppose what I'm asking is how others have handled this scenario in their own projects?

What I have done in the past?: I've gone down the road of refactoring code to fit my ORM of the moment. It was some what painful in that I had to reinvent the wheel - ORM style. I would like to make use of an ORM for an upcoming project and would like to avoid re-inventing the wheel if at all possible.

Thanks to all for your insights and assistance. :-)

- Devon L.

[eluser]WanWizard[/eluser]
For me it is not a matter of "to use or not to use" an ORM.

In the end, and ORM is just a database abstraction layer. Why would you use an ORM? Me, I use it because it allows me to code quicker, I don't have to code all model code from scratch, and all my models behave consistently.

Does it bother me that some third party additions don't use my favorite ORM? Not in the least. What happens in that code, stays in that code and is not visible to the rest of the application. If data from addition needs to be accessable in the application, I write an ORM model for it.

I would never go for altering the third party code. It doesn't add anything, and will create a maintenance nightmare when you want to install a newer version that just isn't worth it.

[eluser]Basketcasesoftware[/eluser]
Yep. I tried starting a thread tonight over that very issue Devon is speaking of. Was hoping to create something to create a layer of abstraction between the DBs and such applications. I haven't had any response yet. And Devon, you can relate to what I'm working on... game engine.

[eluser]Devon Lambert[/eluser]
[quote author="WanWizard" date="1297866846"]For me it is not a matter of "to use or not to use" an ORM.
...
Does it bother me that some third party additions don't use my favorite ORM? Not in the least. What happens in that code, stays in that code and is not visible to the rest of the application. If data from addition needs to be accessable in the application, I write an ORM model for it.
[/quote]

I agree with your point here, in theory, but in practice, writing new code in ORM style, just about any ORM out there, is much easier to work with than straight CI Active Record. Yes, CI's Active Record is very powerful and extremely intuitive, but an ORM can make simple queries that much easier by doing the majority of the heavy lifting for you.


[quote author="WanWizard" date="1297866846"]
I would never go for altering the third party code. It doesn't add anything, and will create a maintenance nightmare when you want to install a newer version that just isn't worth it.[/quote]

Again, I agree entirely with this point, in theory, but in practice it is somewhat difficult to keep that libraries inner workings from interfering with your applications code. For instance, let's take User Authentication library as an example. Say you have to get information on a user for data that SPECIFIC to your site, i.e. User Gameplays for a game site, and then turn around and update that user's information in your table. Well you are definitely interacting with your Auth library, but now your updating a table that was never included with your auth library of choice. Therefore you have to use your auth lib to pull a user out and then update a completely separate table using your ORM lib.

A minor example of the mix/match effect, but hopefully you get the point. Wan, your a seasoned CI expert, you haven't had this issue in the past?

[quote author="Basketcasesoftware" date="1297867674"]And Devon, you can relate to what I'm working on... game engine.[/quote]

haha yes I can definitely relate. Sounds promising, let me know how it's going, perhaps we can team up? ;-)

- Devon L.

[eluser]Basketcasesoftware[/eluser]
I'm beginning to get a germ of an idea of how to create a more general methodology for this. Look for my thread in the Ignited Code forum.

And a team up might be in order. I see you are definitely organized on the distribution and financial aspects. PM me when you get a chance. My email works in my profile too.

[eluser]bunal[/eluser]
Hey Basketcasesoftware,

What post are you mentioning?

[eluser]Basketcasesoftware[/eluser]
[quote author="bunal" date="1297999364"]Hey Basketcasesoftware,

What post are you mentioning?[/quote]
It's an entire thread. And I think I may have worked my way to a general solution.

The problems: Authorization systems and Access Control Layers (ACL) tend to handle their own database access. Additionally there are other issues that prevent any incorporation of such systems/layers into the CodeIgniter framework (CF. Reactor and Core CodeIgniter boards and 'Voice discussions).

The Premise: Authorization and access control systems all require certain database elements and related database functions.

Goals: Create a library or framework that these systems can use in lieu of their own database management functions. This framework needs to be configurable for both the systems' user requirements and the requirements of that system. It needs to meet the existing framework design goals of the underlying CodeIgniter framework. Ideally if all these goals are met then this system should meet the requirements for inclusion into the CI core. It has already been deemed inappropriate for Authorization and Access Control Layers to be made part of the CI framework.

Steps Needed: Identify what the common functionality and elements are.

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