More on ORM and Drupal

Hi, folks. I had a great time at the meet-up and will definitely be coming to the general php one next week.

In the meantime, I'd like to follow up on our discussions of the ways to use drupal-handled information in more general RDBMS kind of ways. If there are any good books that deal specifically with this (I've got Object Oriented PHP and Using Drupal), or other resources on the web, please let me know. Or, if the preferred methods are well-known and easy to explain, someone can just pull me aside at Kildares, and I'll happily buy the beer for the answer. In a nutshell, my question is "is using Doctrine to extend Drupal ContentTypes so they really act like objects in things like reports an acceptable way to go about it, and if so, how hard is it to get right?"

Basically, the thing that really got me interested in Drupal was ContentTypes (and Users). The idea of not having to create add/edit/delete interfaces for various objects (Products, whatever), or write permission management stuff about them, because it's built in to Drupal, is extremely awesome (as it turns out, I'm not finding the permissions stuff terribly easy either, but we'll save that for a different time). Unfortunately I'm having difficulty figuring out how to essentially treat each ContentType as a Class and extend its functionality.

(I've googled various combinations of drupal, ORM, php, doctrine, and PDO, and not been able to find anything about using ORM-like capabilities with Drupal. Though I have seen a few people complaining about that, and a drupal module that allows you to do some doctriney things in Drupal, but it's not immediately obvious which, nor is it particularly obvious if doctrine's /path/to/php/file requirements are particularly drupal-friendly)

For example, I'm pretty sure I've figured out how to create a few new ContentTypes, say Projects and Reports, and relate them to each other and to users, so that on any users page I can see what projects they worked on and what reports they wrote, etc. This is a silly example, but suppose I want to run a report listing all the users who answered "B" to question 5, which is a field on Reports (I realize there might be a Questionnaire module that would work for this particular example, but that's not the point). If I can treat each of the main Types as objects in php, I can solve this easily (if not computationally efficiently) by searching for all Reports whose q5 is B and returning the names of the user associated with them, something like this:

$obj = $somethingmagical->ReportsSearch('q5' => 'b'); //I've got no idea how to get to this stage, but I want an array of reports.
foreach ($obj as $reports) {
echo $reports->user; // if "user" is in fact a pointer to a User Object, I'd love to do $reports->user->Name.
echo $reports->date;
}

It seems like PDO's FETCH_CLASS can do some of this, by treating the result as an object with attributes named after the table's columns, which is very nice. Doctrine appears to sit on top of PDO and further abstract the database connection and map relationships; in a vacuum, doctrine appears to be the right answer, if I can only define the doctrine classes correctly, which requires figuring out where Drupal puts all this stuff in the database. I've figured out that in general, the nid is the primary key for each ContentType, and in one-to-many relationships, it's the pfk on the other table as well (for our above example, if I had a "questions" field and built each Report by adding an arbitrary number of "questions" fields to it, I'd have a content_field_questions table using the nid of the Report as a foreign key); I haven't figured out many-to-many, but I'm sure I can if this turns out to be a reasonable way to go.

If anyone has done this sort of thing before and can tell me the Right Way or Wrong Way to go about it, I'd be grateful. See everyone next week, or next time!

-Larry Miller