RSS feed - Using POG with Flex
- Optimizing your web application
- Regenerating large objects
- PHP4 or PHP5
- New and Improved
- Evolution of a cube
- POG Museum
- POG 3.0 alpha
- Initial Performance results Part 2
- Initial performance results
- Proposal: POG 3.0 object model
- Suggest a feature
- A new year, A new POG release
- Many-Many relations
- POG 2.5 Released
- POG 2.5 beta
- Automatic table alignment
- New version: 2.1.2 released
- RSS should work well now
- RSS feed glitches
- What's new in 2.1.0
- PHP Objects 2.1.0 (preview)
- PHP Object relations FAQ
- PHP Object Relations
- Searching base64 encoded text
- How to debug POG-generated objects
- POG UI Tips
- Featuring Of Interest links
- PHP CRUD
- POG 2.0.1: A better code generator
- A look at the POG SOAP API
- POG 2.0.0 released
- Coming soon: Generate parent-child objects
- Generated abstraction v/s dynamic abstraction
- Zend Framework preview
- Coming soon: Generate Objects through SOAP
- Easily save images and files to a database
- PHP, Paypal & POG
- Five advanced Code Generator tips
- PHP Pagination using generated objects
- PHP Code Generator benchmarks
- Representing database objects using an AJAX Tree interface
- Using SETUP in a production environment
- Description of the generated object package
- Introducing PHP Object Generator version 1.6
- Using AJAX and PHP Object Generator
- When to use Object->SaveNew()
- Generating PHP objects in 2006
- Happy Holidays
- A short video of the POG Setup process
- A sneak peek at POG 1.6
- POG Tip: Field limits
- Previous versions.
- Searching the blog and tutorials sections
- Generating code with "Other" SQL data types
- Five general POG tips
- POG source code locations
- Microsoft SQL 2005 Express Edition
- Impatiently awaiting PHP 5.1 and PDO
- Php Object Generator goes open source
- POG generates PDO compatible code
- Oracle to offer free database
- POG Google group
- Database Wrappers and POG
- Revisions
- The generator blog
- An explanation of the 'Escape' function.
- Mirror, mirror
- Using POG to solve real world problems
- A php object-relational database tool
- A simple and flexible Object Oriented approach to PHP
Back to the Code Generator
The POG Google group
The POG tutorials/code samples
The POG mirror site
POG Tip: Field limits
written 1550 days agoWhen defining objects, one aspect that even the most advanced programmers often overlook is that POG encodes and decodes object attributes on the fly on their way to and from the database using Base 64.
For example:
Movie Object—-> Title = Harry Potter
On its way to the database, POG encodes “Harry Potter” (12 characters) to “SGFycnkgUG90dGVy” (16 characters).
Therefore, it’s a good idea to provide on average 33% more space than what you would normally allocate if you weren’t using POG. *
For example, if you’re storing movie titles and you’re expecting the longest title that your website/webapp will support will be 100 characters long, you probably should be defining the ‘title’ attribute as VARCHAR ( 150 ) instead of VARCHAR ( 100 ). This will ensure that all your information is saved successfully. **
Similarly, if you modify the Escape and Unescape functions with your own encoding or encrypting functions, keep in mind that encoded or encrypted text is usually longer than their plain text counterpart.
=======
*In our case, we believe that a 33% overhead is an acceptable price to pay for the convenience of not having to escape data manually. You may disagree and if you do, feel free to simply comment out the contents of the Escape and Unescape functions.
**Please note that objects generated for PHP 5.1 PDO do not have the Escape and Unescape functions currently. They will be included in POG 1.6 for consistency.
This is a weblog about the Php Object Generator (POG) project, OO PHP, databases and Php code generators in general.
Php Object Generator, (POG) is an open source PHP code generator which automatically generates clean & tested Object Oriented code for your PHP4/PHP5 application.
Subscribe to our RSS feed
Feedback, Feature Requests, Bugs to:
The POG Google group
Send us a Hello through email
* Data Integrity: simply that the conversion of text & binary information is retained in and out of any database using this type of encoding. Thus it is less trouble to pass/retrieve information to/from a database using encoding/decoding.
* Reduce hackability: we know that passing in direct text content into/out-of the database via inserts/selects could cause undesirable results and allow information to be inserted/recovered that shouldn’t otherwise be. When doing a security audit, this may become more obvious.
* Data obsfucation: There is a proposed law (i.e. in California) that [will] require data stored in databases to be unreadable by theives if the software is to be used in that state. The purpose of this is to protect personal privacy and information. Although this is not encryption, it is a step towards this end. At least it makes it more difficult to peruse at a glance.
I know that there are many arguments going each way and that picking one over another is difficult to always justify. That being said, the encoding has proven to be very useful in many situations and the performance cost has been quite minimal. There are also some clever optimizations that can be employed for transferring larger data bits more directly from the database to a remote client. Things that come to mind are SOAP transfers and images.
— Mark Slemko Dec 20, 12:27 PM #