Propel Stuff

I have spent most of this last week fiddling with Propel trying to get it to suite my needs. Overall I would have to say it’s worked pretty nicely. There is some quirks about it that I absolutely can’t stand. Since no one is in their channel on IRC I figured I would just write them down here in the hopes that someone, someday, that knows something about the internals of Propel can help me out.

For those that don’t know what Propel is: Propel is a full-service object persistence and query toolkit for PHP. I use to use my own library for object persistance, but I just no longer had the time to develop on it and propel did everything I needed much better. (For instance, my library wouldn’t generate my stubs for me :(.)

I have several different applications that I do constant work on for this example I will use two of the applications, one of them is a product catalog and one of them is a CMS system. In many of these application, there are several domain level objects that are actually shared throught several applications. One of the objects that are shared between my cms and my product catalog is a database I use to hold media file data (images, flash, pdf, word docs, anything really.)

I like to keep most of my domain level classes (with the exception of a
few extremely specialized ones) in a central location on my production
and dev servers. This media object is one of them. If I make a change
to my media object to allow for some more meta data to be associated
with each object I want these changes to effect all applications that
use this object. If I all of a sudden want to add thumbnail support to
my media object (it’s already there btw, just using it as an example.)
I don’t want to have to maintain seperate copies of a media object to
allow this.

Now, the way the propel generator works, is it allows you to generate source code for database schemas that are defined in xml files. It gives you some degree of organization to the resulting classes by allowing you to assign databases, or even tables to specific packages. The resulting code is then seperated into directories with the same names as the package. So I have accordingly used this to my advantage. I have one package called medialibrary that contains the object classes for the tables required by the medialibrary. I have another package called productcatalog that holds those classes. I of course don’t include the medialibrary classes in that package as really they are more of an ‘add-on’ to the product catalog (granted, very few people would want a media catalog with no pictures :P.)

In order to prevent my schema files from being inordinately long and to keep the generated sql files somewhat specific to each application. I have a seperate schema xml file for each package. However, obviously some of the tables from the productcatalog package are going to need to link (foreign keys) to tables from the medialibrary package. Thankfully there is a tag supported by propel called <external-schema> which allows you to pass a filename to another schema file as an attribute. The generator will then open this schema and use it as a reference to figure out what functions are needed. However, whenever a group of tables is opened via external-schema, the package names are overwritten! Which mean all of the classes in my productcatalog package that depend on classes in the medialibrary package are attempting to load them from the productcatalog folder. I can’t figure it out.

So, if you know alot about propel and can help…please oh please oh please leave a comment.

Share
This entry was posted in PHP. Bookmark the permalink.

2 Responses to Propel Stuff

  1. Stephan Wentz says:

    Join the channel again and contact me, [temp]. Maybe I can help you ;-)

  2. mike.lively says:

    I ended up solving my problem by commenting out the code that was causing the tables being loaded from an external schemas to have their default package overridden. This is something the propel team should really think over though. After digging through their code, there is no other way to have tables in one schema file, reference tables in another schema file without putting those tables in the same package.

    For those that care, I just commented out line 196 in propel/engine/database/transform/XmlToAppData.php

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>