“phrames” framework/ORM now on github

While in the midst of readying some fairly large projects at work, I haven’t had too much time to progress with my last update of my “phrames” ORM/framework. However, I am happy to announce (to whoever is willing to listen) that I’ve published my work to github! I’m really hoping that, first and foremost, this project can gain a little more ground to those that might be interested in it. Progress has been slow and steady, and quite obviously more a personal effort than anything, but I’ve been loving some of the feedback I’ve gotten. I believe that if there’s just 1 person out that that uses my code, contributes to it on github, or even just learns something from what I’ve offered then mission accomplished.

That being said, I’ve more been a lone developer for essentially all of my career to date. My experience with version control systems is limited at best, especially on a multi-developer level. I’ve only ever used it for keeping track of my personal changes/commits and versions, so if you would be so gracious as to make some changes to my project and share them with me, please bear with me while I learn and adjust to these new methods.

Find my project phrames on github!

5 thoughts on ““phrames” framework/ORM now on github

  1. Quadric

    You’ve made great job. I’ve also want to make this kind of “port” but stuck in queries (i though about making a queries in string) and defining model column. But i’ve got some experience and ideas to share.
    I really like to help you with your project (if you would like). If so, please contact me on mail.

    furthermore i’ve got some questions:
    1) Why do you use pear db instead of PDO?
    2) You have got a deprecated “split” function in Fields class (line 39). You should use an “explode” function
    3) Do you plan making models aware of table fields and their types? For example for making migrations (like South) or validating forms
    4) I think there is something wrong when chain filtering on foreign keys. (based on example). If i got this: Product::objects()->filter(manufacturer__name__contains(“s”)) i got products with manufacturer cointaing letter “s” which is ok
    but when i make something like this Product::objects()->filter(manufacturer__name__contains(“s”))->filter(manufacturer__name__contains(“d”)) i got all product entries even when there is no “s” and “d” in manufacturer name.

    Again: If you’re interested in some kind of cooperation please contact me on mail. I’m very experienced in PHP and django-python and i’m in currently developing php framework which based in django’s (and other popular php frameworks) best ideas
    where i’m always focused on code optimizations, speed and readability.

    • Andrew

      Hi Quadric,

      Thanks for the comment. Unfortunately I’ve been absolutely swamped lately and haven’t had much time to work on this — hence the lack of github commits. I’d love to e-mail you once things slow down a bit and I have some free time to apply to this project.

      To answer a few of your questions:

      1) This ORM has kind of evolved from a custom one I’ve been using for quite a while. The use of PEAR DB is just a relic of this old ORM that I haven’t had time to rewrite to this point — consider it legacy code that I need to update
      2) Just stuck in old ways… I can easily go through and clean up a lot of deprecated function use
      3) My initial mental plan was, once the basic ORM was developed, to integrate a good templating system (like Smarty — with a whole lot of fixes — or develop my own custom templating engine), in which case I would implement the ability to specify custom field types for UI form purposes, tightly integrated with a solid template engine. That being said, my ultimate goal really is just to keep this project lightweight — or at least very modular. If I wanted to integrate this ORM with a templating engine, I would certainly want the ability to not have that a requirement to use the ORM separately. Hopefully that makes sense.
      I haven’t heard of South, but I’ll certainly look into it!
      4) Consider that lack of (unit) testing. If you read through a lot of my older blog posts about this, I’ve really tried to stress that this whole thing is something I threw together rather quickly and I pretty much guaranteed it wasn’t going to be anything close to perfect. This will certainly come in time.

      I very much appreciate your offer and I certainly would like to take you up on it. I’ll e-mail you as soon as I can guarantee at least a couple of hours of free time a week. In the mean time, if you have any links on github/etc to your own work I would love to browse through.


      • Hi Andrew,

        I see that you don’t have time for phrames yet 🙁 Will you continue in developing this project?

        My answers:
        1) I guess it will be good to split connection types for database backends, including schema browsing for making migrations (check answer 3). I think PDO is a good backend for this)
        3) For template engine very similar to django there is a Twig. Looks and works very good. I used it for one of my projects. About south – django makes ORM “Model oriented” not “Database oriented” which means that database is created from model structure which makes sense for me. So when creating models it’s neccessary to tell info about properites/columns, like so:

        class Channel(models.Model):

        name = models.TextField(u’Name’)
        order = models.IntegerField(u’Weight’)
        def __unicode__(self):
        return self.name

        So south creates schemamigrations and migrate them into database. It will create SQL channel table with column name of type “text” and order column with type “integer”.

        So it will be good to have this in PHP, but insteda of propel or doctrine i don’t think it’s good to have it declared in xml’s or yaml’s. It maybe something like this

        class Channel extends Model {
        $name = array(‘type’ => ‘text’);
        $order = array(‘ty[e’ => ‘integer’);

        I’ve changed structure to PHP namespaces so it looks much better. What do you thing about namespaces?

        And some sort of links to my work
        (i can’t show you much of my work becouse of company restrictions).

        (everything is in polish)

        http://outlay.goblix.pl (Django)
        http://you-ebook.pl (PHP with my own framework)
        http://rct.goblix.pl (This is PunBB Forum but with lot’s of extensions i’ve made)
        http://quadric.goblix.pl (This is my personal blog)

        I still wait for an e-mail from you when you got some time.

        • Andrew

          Hey again,

          I know, I’ve been busy as heck lately and just haven’t had much time to dedicate to this side project. However, I have done some work on a pretty major overhaul/rewrite that so far I am quite happy with. I have a long ways to go still, a lot of testing and code clean up, but I’ve done a lot better job this time with properly separating the components into different classes (Models/Objects are defined separately, I’ve wrote it in such a way that alternate DB drivers could be used, I’m now using PDO as you recommended. I also have some plans on tightly integrating an intelligent caching mechanism (this will also be implemented properly to allow for different “drivers” if needed, i.e. memcache, Redis, etc).

          I’m very hesitant to plan for any sort of Rails/django-style database model generator. Ideally I want to keep this “framework” as lightweight as possible, to be used more as a rapid-development assistant. Personally, when I’m working on any sort of project, I typically always draft the database schema first (after defining the requirements) to ensure I can properly normalize the tables. I definitely don’t want to replicate the database field-by-field in my framework model — I wanted to only define my models using the key fields/relationships (i.e. one-to-one, one-to-many relationships) and leave the rest of the native/root variable types (ints, strings, etc) to PHP. Hopefully this makes sense. Bottom line: for rapid development, I don’t want to have to replicate my carefully constructed database schema all over again in my PHP models. I also don’t prefer my database schema being auto-generated from my ORM model. This is all just personal preference. I’m trying to design phrames in the most flexible/expandable way possible.

          I have done something very similar to what you’ve suggested, here is an example of how I’m defining Models in my rewrite so far:

            class Car extends Model {
              protected static function fields() {
                return array(
                  "id" => array(
                    "type" => "ID",
                  "make" => array(
                    "type" => "Make",
                    "required" => true,
                  "name" => array(
                    "required" => true,
                    "__get" => function($v) {
                      return strtoupper($v);
                    "__set" => function($v) {
                      return strtolower($v);
              public function __toString() {
                return $this->name;

          I think namespaces are a fantastic addition to the PHP language, and I’m definitely interested in implementing them with this project, I just want to get the core functionality in there first (and hopefully some legitimate unit testing). It’s not a huge codebase, so adding namespaces won’t be too difficult.

          If you want to take a look through my rewrite so far, feel free. I’ve uploaded it to the link below. Just don’t judge me just yet on code quality — I’m just trying to get this rolling! 🙂


          Once this is in a more usable state I will glady upload this over my existing github project and send you an e-mail.

          Thank you so much for your support and interest. All the best,


          • Hey!
            It’s great to hear from you. I’m happy that you continue this project. I’ve checked it and it looks much better. No problems running it on PDO. I’ve made unit test for Article model and everything works ok. Check if you like: http://quadric.goblix.pl/storage/ArticleTest.zip

            I really hope that this project would stay simple and elegant (as far as php allows to do that) but i’m very sad that you prefer database oriented approach than model oriented approach. In my job when develop an application we works on a local sqlite database. But the staging and production system is on postgresql. When i inform a php model what columns it has and what type it is – the migration system can easily put schema changes into my local sqlite and when i deploy application on production system it migrates changes to postgresql. I don’t need to look into database structure because i don’t really care. If this is mysql, sqlite, postgresql, oracle, mongo or sth else. Other example – how will you optimize table joins? In django there is a “select_related” option. Django will make just one sql query (join table A with table B) and split columns into object A and B. Without column info it’s impossible to do that because you can’t get A.* and B.* having known in a result what columns is from what model. Of course you may try to explore database structures in system tables of current DB adapter but i guess has not a good performance.

            But this is my approach and my experience and this is your project. Maybe some day you’ll allow me to fork your project and change it 😛

            Anyway.. great that you continue this project. I look for updates everyday. When you think of this project to be more “production ready” i could help you with making a postgres adapter or maybe write some unit tests. Let me know.


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=""> <s> <strike> <strong>