Php Object Generator Blog

Using POG with Flex

Recently, we’ve been contacted by Justin Opitz, a flash developer, because he was trying to get POG to work with Flex. After playing with the configuration for a few days, he was able to get it working. His solution looks like it would be extemely helpful to anyone else trying to get Flex working with any lightweight PHP library.

Justin’s POG + Flex solution

We welcome other input from other flash developers who have worked or are currently with POG. So, don’t hesitate to contact us with your problems/questions.

Optimizing your web application

So you’ve got your web application up and running. Maybe you’re using POG for all your database abstraction needs, maybe not. But you want to optimize your entire application/website and make it snappier and more responsive. Here are a few things that we’ve done ourselves and definitely recommend:

1. First and foremost, if you’re not using POG as a database abstraction tool, you should. Here’s why. We’ve optimized the hell out of POG and released version 3 a few months ago and it’s the fastest thing we’ve ever seen in its category.

2. Use HTTP compression (aka gzip) on your server. If you’re running Apache as your server, you’ll need to enable/install mod_gzip. You do need root access if you want to do it manually. Else try contacting your host provider and ask that they enable it for you. This should speed up the loading of pages significantly.

More info:
Additional info 1
Additional info 2

3. Use an opcode cache. We use XCache and we love it. XCache essentially caches all the POG classes in memory, so that each time a method is called, PHP doesn’t have to interpret the code again and again.

These 3 steps can dramatically boost your application speed. Give them a try, and let us know if you find that it helps, or if you know of any other ways.

Regenerating large objects

If you deal with large POG objects frequently, you probably noticed that the @link generated by our code generator become quite bulky and cannot be handled by some browsers such as Internet Explorer. IE truncates the @link, thus rendering it useless.

If you find yourself in such a situation, we have a solution for you: regenerate.php which allows you to easily regenerate large objects that IE cannot handle.

You could also switch to firefox:

PHP4 or PHP5

As more and more hosting providers offer PHP5 as part of their PHP hosting package, developers are faced with a choice: should you stick with PHP4 or migrate your applications to PHP5. It depends:

If you’re starting a new project using POG, we highly recommend starting fresh with PHP5. This is the version we ourselves use when creating applications. Why? POG is best appreciated if your entire application is object-oriented (not just the db related stuff that POG does). Cool Things in PHP5 and Go PHP5 are two good resources that give some additional information about why you should consider upgrading to PHP5.

When we started the POG project a year and a half ago, PHP5 adoption was already accelerating; Nevertheless, unlike other ORM libraries or frameworks, we decided to still support PHP4 with almost the same feature-set as PHP5 in order to be useful to the broadest base possible. PHP4 used to be the default language on the POG frontpage. In 3.0 however, PHP5 is now the default language. This does not mean, however, that we are going to drop support for PHP4 anytime soon.

In fact, POG itself, is written for PHP4 and needs some tweaking to run on PHP5. We plan to re-write it soon so it can be run on systems running PHP5.

How about old-er projects? Should you upgrade? Depends. If you’re application is based on POG, we believe upgrading should be a breeze. If you intend to add major features to your project, we recommend you upgrade to PHP5. Support for object-related ‘stuff’ is simply better, while in PHP4, ‘hacks’ are often required. If your project is nearing the end of its lifecycle, then upgrading doesn’t seem worth the effort.

New and Improved

If you’ve used POG in the past, you probably noticed that we’ve recently updated the look and feel of the website, to go along with the latest version of the code generator. (Version 3). We’ve been planning and working on this update for a long time, and we believe that this version is the best we’ve ever released since we started this project almost 2 years ago now. Our gratitude goes entirely to past and present users who’ve given us their invaluable feedback and suggestions. We’d like to mention that one user stood above the rest when it came to making so great suggestions and feature requests: Andy Law. Thanks to you and everyone else, we believe that POG further distances itself from any other PHP Code Generator in terms of ease of use, simplicity, performance and extensibility.

Before we proceed, if for some reason, you’d like to still use the previous version (maybe you’re in the middle of an ongoing project), it can still be accessed at:

http://museum.phpobjectgenerator.com/2.6

What’s New in 3.0
Pog fetches result set arrays where possible (big performance boost)
Data encoding is handled within database
Plugin interface
Data encoding is off by default
Data encoding sanity check added to setup
Delete deep and across for siblings
Getlist accepts column names as filters
Getlist, GetChildren and GetSibling return all results if fcv_array is null
Better session etiquette
Added database wrapper class for PDO as well. Improved PDO performance
POG_Base base class is now extended by all objects
Unit tested plugins, including PHP4
Made plugin API, POG Base API and Database API uniform to prevent plugin versioning

Database Wrapper improvement/refactoring
Database::NonQuery() performs a non-select query and returns affected rows
Database::Query() performs a select query and returns the affected rows
Database::Reader() performs a select query and returns dblink to result set
Database::FetchRow() perform fetchrow on Reader() results
Database::InsertOrUpdate() performs an insert or update statement, returns the id of the insert/update

What you can expect with the new version
If you’ve never used POG before, you should still find POG intuitive, easy to understand and use. If you’ve used any previous version, you will notice 2 or 3 things:

1. Performance is a non-issue even with very large record sets. (almost as fast as using direct SQL statements).
2. Data encoding has been turned off by default.
3. The code generated code is cleaner and much much more extensible (either by official or third party plugins)

Our blog and Discussion forum contains more information, discussion and threads related to the version 3 transition. Should you need even more information, help or guidance, please leave us a message on the discussion forum and we’ll gladly help.

Regards,
The POG Team.

Evolution of a cube

Over the years, Jonathan, our talented designer, played wnd tweaked the POG logo to represent the POG features, as they evolved.

When it started about 2 years ago, Jon was assigned the task of designing a logo for what was then, a rather crude code generator. How do you faithfully represent something as basic as a generator, yet make it visually appealing? This was the first iteration:

Simple and to the point. We decided to use it on our frontpage. The hand-drawn look illustrates exactly the raw/undeveloped state in which the PHP objects currently are when they are being defined by the user.

We then needed a variation of this idea for Page 2, when the objects have been generated. Jon came up with a ‘golden’ look for the cube. The generated code is as good as Gold, he reasoned. We decided he was right.

Then came the time to design some other variations of the cube for our Setup process. Once again, the design was simple and elegant.

Now, as we get ready to release version 3, we wanted to tweak the logo a bit more so that it reflects more accurately what we’re trying to achieve:

1. Flexibility
2. Speed and
3. Simplicity

And the result is:

I personally think that once again, Jon was able to capture what this next version of POG is all about and translate it to something as simple as a cube. To him, I say thanks once again for a job well done. Questions, Comments? Talk to us

POG Museum

To prepare for the 3.0 release, we’ve tagged 2 other milestone versions in the SVN directory:

version 2.1
version 2.6

To download the code, simply use a SVN client (username:guest, no password)

so that users can still download previous versions of the generator with ease. Although we do recommend using 3.0 as soon as it’s released, we realize that some developers may still want access to these 2 important releases.

Release 2.1
Supports other databases besides mysql: firebird, sqlite, postgresql etc. This version supports 1-1 and 1-many relations. Includes POG Setup.

Release 2.6
The most stable and polished version up to now. It supports 1-1, 1-many and many-many relations. This version supports mysql 4x and 5x as the database. Includes POG Setup.

Release 3.0 (future)
Supports mysql only. Everything from 2.6 + Significant performance improvements in certain areas, plugin (extensible) architecture. Includes POG Setup.

As soon as 3.0 is released, we’ll tag it as well and add it to the list.
For those of you not interested in downloading the code and simply want access to the online generator, you can access both of the mentioned releases in the POG “museum” at:

http://museum.phpobjectgenerator.com/2.1
and
http://museum.phpobjectgenerator.com/2.6

Note that we will actively develop and support 3.0 when it is released. The previous versions will not be actively supported. They are provided for convenience.

POG 3.0 alpha

We’ve just made a commit of the alpha version of 3.0 to the SVN
repository.

The version has also been refreshed on http://beta.phpobjectgenerator.com

This early version is fully workable (though there are still other
features we need to add) and is meant for hardcore POG developers to
play with.

Things to look for in 3.0 alpha.

1) Speed.
2) Plugin interface.
3) Other smaller improvements.

For more details and to give feedback, take a look at the 3.0 alpha thread

Initial Performance results Part 2

A couple of weeks ago, we published some of results of the performance tests ahead of the upcoming release of 3.0.

Here are some more results obtained for the same amount of data (5000 rows, or should we say objects).

After some more optimizations, mostly by letting the code generator do what a code generator does best: generate all the object-specific attributes, within the php files, we eliminate the need for run-time evaluations and reflections, allowing us to shave off, on average 100ms more off the already-promising results from last time. See for yourself:

With these promising results, our intent, is to break the annoying myth that some have, that POG, or ORM in general, is a luxury that comes at the expense of performance and scalability.

Initial performance results

The initial performance results between 3.0 and the current version of POG (2.6) are very promising! See for yourself:

Profiler results for GetList (5000 objects) – POG 2.6

Profiler results for GetList (5000 objects) – POG 3.0

As you may have noticed in the screenshots, the initial intention for the tests were initially to see if the new extendable architecture planned for 3.0 will affect performance in a negative way. Not only did we find that it wouldn’t, but combined with the optimization efforts that we also have planned for 3.0, we find that the next version of POG will be an order of magnitude faster for operations such as GetList.

We are trying to finalize the design of a nifty little feature before we are able to publish the plugin model so that developers can start converting their custom code in POG plugins. We’ll post more details soon.

Proposal: POG 3.0 object model

There are some exciting changes in the works for the POG 3.0 object model. We know that our original manifesto has been (and still is) POG is a code generator, not a framework. However, to put the new model into context, we cannot avoid but talk about how we think POG objects will be used in the context of a web application and therefore, what follows may sound a litte bit frame-worky. So we apologize in advance about that.

We believe this is the simplest and most traditional way POG objects are used in a project.


- 
- 
-

Developers who then wanted to customize the generated code could either:

Manually edit the POG objects by hand
Create objects that extend the generated objects and put their custom logic/rules in the extended objects.

Note: we personally have been using #2 up to this point.

The “edge” that this model has over other dynamic ORM frameworks is that since the code is generated, it is:

clearer/more easily understood by the developer.

doesn’t need pages of API documentation

easier to use

works better with IDEs that support code completion.

faster

more lightweight

less coupled with other application code

extensive changes can be done to one class without effecting everything – i.e. customizing a special class is a breeze, whereas in a framework, adjustments to the framework itself can prove catastrophic for special
cases.

The one main drawback was that it was less extensible than dynamic frameworks: if the developer manually modified the generated objects to include custom code, these changes would have to be tracked/updated whenever the objects were regenerated. If the user extended the objects with custom logic, the custom logic would be immune to code regeneration, but could not be used across different projects.

Being more extensible:
In order to achieve a greater level of extensibility and still keep the advantages mentioned above, POG 3.0 will have a slightly modified object model that will allow for POG plugins ...or should we say … Plogins?! . Aaanyways, this is how a project may look like under 3.0

- - - -

Plugins will allow developers to have a larger set of available features from which they can pick and choose the ones needed on a project level and not have unnecessary things bundled to their project. The basic POG Essentials and POG Relations methods will be generated as usual, but additional functions such as those used for data transformation, reporting, data manipulation etc can be added/removed at will through plugins. This model thus provides extensibility while keeping things as light as possible.

In the new model:

1. All generated objects will inherit from a POG_Base object which will provide general abilities to all POG generated classes
2. What used to be in the database object will be moved to the POG_Base object (i.e all the db connection handling methods), which will simplify and minimize the code in each object
3. The POG_Base object will also contain common methods that can be used across objects and which can be used by POG Plugins
4. Plugins are objects that reside in a special plugin directory.
5. Plugins can inherit from the POG_Base object. (optional)
6. Plugins can be used across projects and shared among developers.
7. Plugins objects must have unique class names that are different from the built-in generated methods (e.g. Save, Delete etc)
8. Plugins must implement an Execute() function, but everything else is fair game.

To summarize, in addition to the performance enhancements and other cool suggestions by other POG developers, the main thing we wanted to take into incorporate in 3.0 is
How to make POG more extensible
How to encourage more developers to contribute
How to make the overall POG functionality more useful. and finally
Was there a model change needed to achieve the goals above. The answer to this question was obviously yes, and the bottom line is, we hope that this model makes POG more useful and appealing to developers.

As a last note, we’d like to thank all current POG “hardcore” developers who have been giving us great feedback in our forum, in particular, Andy Law, whose ideas kind-of inspired this new model for 3.0. Thanks Andy!

Suggest a feature

We’re currently looking for feature suggestions for version 3.0. Please let us know on this thread of our forum. The thread mentions some of the current ideas we’re exploring, such as:

-> address performance issues w/ and w/o encoding
-> plugin architecture + sample plugins
-> allow encoding on a field level (instead of project level)
-> simple data integrity checks
-> code cleanup
-> compliance with strict mode in PHP5/MySQL5

We’d love to hear your ideas, so let us know as soon as you can what you think POG is missing and how we can improve it.

A new year, A new POG release

POG 2.6 has been released a few weeks ago. This release addresses recent Relations bugs that have been discovered since the release of version 2.5

For the specific listing of bug fixes, visit our google group

We’ve also taken the opportunity to include in our source code, internal PHPUnit tests against which we test the generator before any release. These unit tests are different from Setup tests that are included with all generated objects since version 2.1

While the Setup tests make sure that all db operations work correctly (Inserts, Updates, Deletes etc), the phpunit tests, on the other hand, ensure that the objects behave as a expected when they are used programmatically by the users. This may seem a bit redundant, but essential, the phpunit tests cover areas that may get broken when the generator source code is modified, whereas the setup tests cover areas that may be get broken when the objects are modified directly. Thus the phpunit tests are a superset of the setup tests.

The main motivation for including those tests was to encourage code modification/contribution of the generator from other developers, and to ensure that the modifications are reliable. The bottom line is that we believe that this will help us keep and even increase the level of code reliability as we/others introduce more useful features in the generator.

If you’ve made modifications to the generator source code, and want to run the tests (on Windows), you need to first make sure you have PHPUnit installed . Then, run setup for the sample app corresponding to the installed PHP version. If you have PHP 4 installed, run the /tests/php4/app/setup/index.php script. If you have PHP 5 installed, run the /tests/php5/app/setup/index.php script. This will create the sample tables and perform the SETUP tests.
Finally, simply run the file “runtests.bat” in the test/phpX/ folder where X can be 4, 5 or 5.1. You should see something like this:

If you have any problems running the tests, ensure that the path to phpunit.bat is included somewhere in the PATH environment variable in Windows. If you have any comments or questions on the latest POG release, feel free to contact us on the POG Google group

Many-Many relations

Since POG 1.0 was launched about a year ago now, there has been numerous requests for object relations. POG 2.0 addressed the issues of parent-child (1-many, many-1) relations. Still, more work needed to be done for POG to really be useful in situations where many-many relations were needed. POG 2.5, released about a week ago, finally provides a simple, yet, powerful solution: Sibling Relations.

In the POG world, a sibling is an object that relates to one or many other sibling objects. Real world examples include the relations between Magazine and Subscribers: A subscriber can subscribe to one or more different magazines.

The object methods generated by POG to abstract many-many relations are similar to the ones generated for parent – child relations. We kept the API consistent so that the objects remain intuitive, and yet, are more powerful. The programmer can almost forget the underlying relations.

For instance, let’s say we have a Magazine and Subscriber object which are siblings. To associate a Magazine to a Subscriber, we only need to do something like this:

$subscriber->AddMagazine($magazine);

The thing to note here is that if Subscriber and Magazine were parent and child, instead of siblings, the code would still be

$subscriber->AddMagazine($magazine);

On the database level, however, the way the data is stored by POG is quite different. In the case of a parent-child relation, the child simply refers to the parentId using a column in the child table. In the case of siblings, POG generates a mapping (join) table which stores the sibling1_id and sibling2_id of related sibling. The data is inserted, retrieved and deleted from this mapping table transparently and does not have to be accessed directly by the developer.

More info on sibling relations can be found in the POG relations PDF document

We hope that the introduction of sibling relations will help accelerate your development even more.

POG 2.5 Released

This is perhaps the biggest update we’ve done at one time and we’re relieved it’s finally out of the door. Overall POG 2.5 is the result of developer feedback and our own observations while using POG recently in a few medium/large projects.

By dropping out-of-the-box support for databases other than MySQL for now, we’ve narrowed our focus in order to deliver a product which is more complete and stable. We also want to accelerate POG’s release cycle, and having to maintain several databases that very few POG users (including us) use was creating some slowdowns.

The purpose of this release is to improve on the code base that we had, and provide an even better PHP ORM generator which now fulfills, we believe, 99% of all db requirements in a typical web application. The implementation of Many-many relations in POG follows the mantra that we’ve had since day 1: Keep things clean, simple and easy to use. As such, when you generate Sibling (many-many) objects, you’ll quickly realize that you can almost forget/not care about how the relations are being handled on the database level and instead, focus on application logic. We’ve also kept most method interfaces consistent, for backward compatibility. Thus, upgrading a previous project to POG 2.5 shouldn’t be too difficult.

Setup has also been improved to provide a better scaffolding environment. The ability to re-initialize data in all your tables with a few clicks will surely be helpful. We know that it has for us.

Entire changelog

1. Dropped support for databases other than MYSQL
2. Improved Parent-Child (1-many, many-1) relations. Bug fixes include – checks that prevent same child from being added more than once to the childList – documented a php ‘bug’ where adding children through a loop must be done by reference – SetChildrenList now does what it was supposed to do: commits changes to the database, making previous children orphans.

3. Implemented Sibling (many-many) relations model in Generator as well as Setup
4. Table structures are now optimized (using NOT NULLS and Indexes)
5. New crud method: DeleteList
6. All %List CRUD methods have been made fairly consistent. They now accept the same field-comparator-value array variable ($fcv_array)
7. All %List CRUD methods are able to generate Disjunctive Normal Form (DNF) queries. i.e. queries containing “OR”
8. Improved setup options – table to object alignment – drop and recreate tables – drop, recreate tables and re-initialize data – allows bypassing of unit tests – warnings before destroying data – pagination
9. Fixed all reported/known bugs up to this date.
10. Fixed some issues (ajax) reported with Setup and IE7
11. Regenerate object url is now configurable
12. Updated all documentation
13. Fixed reported annoyances: – internal metadata array (pog_attribute_type) now keeps the attribute names in their original casing (instead of lower case). If you’re updating an existing project, this can now cause unpredictable results in badly formed Get%List request, if you used to pass attribute_name as lower case. Previously POG would produce the intended result but not anymore in this case. Please review your code thoroughly if you’re upgrading an existing project to 2.5. – Generator gives warning when the attribute list contains duplicates.

POG 2.5 beta

For the past 2 months, we’ve spent most of our time using POG in our own web application projects. We’ve taken our own experiences with POG, as well as the feedback we’ve been receiving and made some major improvements to POG’s functionality. The new features will be available in the next version, POG 2.5 which should be released within the next week or two.

A preview of POG 2.5 can be found at http://beta.phpobjectgenerator.com

Everything is almost there, we’re now polishing some minor things up. The main changes over the current version are:

1. support for databases other than mysql have been dropped.
2. many-many relations are now supported and unit-tested for all
versions of php (4, 5, 5.1)
3. addition of 1 new crud method: DeleteList
4. all %List crud methods are now capable of accepting ‘OR’ in between
conditions.
5. bug fixes. all previously reported bugs have been fixed.
6. major improvements to parent-child relations have been implemented.

The documentation will be updated soon to reflect the code changes.

In the meantime, feel free to play with POG 2.5 and let us know what you think.

Automatic table alignment

Automatic table alignment was recently introduced, and we’ve personally experienced a further increase in our productivity. Letting POG Setup take care of keeping objects and tables aligned, really allows you to forget about the underlying database. (Sometimes a bad thing though!)

The following are real-life cases where we truly found automatic table alignment indispensable:

Scenario A
Schema Changes without any hassle
While working in a small team of 3-5 developers, very often, one of the developers will need to modify the underlying table structure to accommodate for a new attribute. POG setup allows the developer to regenerate the PHP object class, align his local database and commit the new object(s) to a common code repository when the code is deemed satisfactory . All the remaining developers then simply need to do a repository update and run POG Setup. Voila! they too have the latest database schema on their machine with database access code that is 100% aligned with the database.

The other side
I have personally experienced work environments where the responsibility boundaries were marked at the database level. That is, where there is a database team and an application team. The problem with this ‘configuration’ is that there is often a misalignment between the database and application because the teams often work at different speeds or due to miscommunication. This is why I personally believe that the way POG handles things allows for more efficient web teams.

Scenario B
Migrating an application from a development machine to a Production machine

When dealing with a database application, it’s almost certain that the database schema will change by the next version release. Usually, when the application goes live, the production database has to be modified so that it contains the new schema.

POG Setup allows the release manager to automate this step. A script can be written to upload the newest source code and run setup at a specific time. No manual steps are then required and what you have is effectively an automated ‘build’ system.

There are a few other scenarios I can think of where the usefulness of automatic table alignment really shines, but the 2 use-cases outlined above are the main ones we’ve personally experienced so far while using POG.

Hope this has shown at least a little bit why we love POG so much!

New version: 2.1.2 released

Last night, POG was updated to 2.1.2, which has some nice improvements over 2.1.0 & 2.1.1. Release 2.1.0 addressed some shortcomings that Setup previously had regarding related/connected objects. 2.1.2, yesterday’s release, addressed a bug identified as well as improved the rendering of connected objects.

Rendering – the old way
In 2.1.0 & 2.1.1, POG setup did not render connected objects fully. i.e. only the non parent/child attributes were rendered.

Rendering – the new way
In 2.1.2, POG setup now renders connected objects fully and gives a true hierarchical view of connected objects. For e.g. if you have an Author object who has many Books, Setup now displays BookList as a clickable node attribute. When expanded, setup renders all book objects and attributes. The following is a screenshot example of how Setup renders parent/children.

Fixes:
The major bug fix made concerned automatic table alignment and connected objects. Previously, the bug caused some object relations to be ‘lost’ each time setup is ran because the parents/children column were being dropped and recreated under certain circumstances. This has now been fixed.

Other improvements
Other improvements include – Prevent timeout/max execution time issue when dealing with a large number of objects during Setup and Update – Added circular progress indicator in a few places – Fixed a few setup glitches here and there.

Hope this gives an overview of what has been improved in the latest version. You can always download and take a look at the source code.

Next expected release is now 2.2.0 which will finally introduce many-many relations.

RSS should work well now

If you have any troubles, please let us know. Thanks.

RSS feed glitches

In the next little while, some of you might notice a few RSS feed glitches as we move our feed to Feedburner. This will make the POG RSS feed more reliable and stable.

Sorry for any inconvenience.