One of the PEAR modules I’ve been making extensive use of is DB_DataObject. For a while I toyed with writing a custom DataObject system for the current project, but PEAR’s offering seemed to have pretty much everything I was looking for. Overall, it’s made the development process much more straightforward than it would otherwise have been, but I did run into one unexpected problem.

I have a lot of table links specified in the configuration file and I suddenly discovered that some of those links weren’t being made as I expected. It turns out that DataObject loads all the links into an associative array, indexed by the field being linked. This means that if, say, you have a member id linking to a whole variety of tables then only the last link specified will be recorded.

Doing it this way definitely keeps the class’ internal logic clean, and most of the time it’s possible to design the application to work within these parameters, but in a couple of cases I’ve found it would add far more complexity than it’s worth to do so. I scoured the documentation for support, but couldn’t find a clear explanation of how to deal with my situation. In the end, with some help from the PEAR email list and a little time looking through the source code I came across the following:


where $registration is your main table, and its field registrant links to the position table’s ‘member’ field. This method along with judicious use of the whereAdd method seems to have everything back on track.

Tags: , ,

1 comment