> 1) Optimization strategy used:

> This was one of the main focus for this release.
> 1.  Minimize the # of calls to the database by entire result sets for
> GetList, GetChildrenList, GetSiblingList
> 2.  Smarter SQL queries. POG now lets the database handle the data
> decoding for queries that were inefficient such as the ones that
> involved sorting, limits.

> Database encoding is, by default, turned off. POG also provides a
> base64 plugin by default. To enable data encoding, the user needs to
> run setup, go to the plugins tab, and enable the base64 plugin there.
> Enabling the plugin will, in effect, install a base64 custom function
> into the database. Then the user can set encoding to 1 in the
> configuration. When POG sees db_encoding = 1, it assumes that the
> custom base64 function is installed and uses queries that use this
> custom function.

> #1 and #2 give a significant performance boost as outlined here:http://www.phpobjectgenerator.com/plog/article/146/initial-performanc...

> To shave off a few more seconds on very large datasets, the generator
> hardcodes things within GetList and Get instead of trying to perform
> those 'calculations' at run time. Note, Andy, I will comment on your
> points regarding this in my next post.

> What we still need to work on in terms of optimization is to create a
> plugin that will allow loading of children/siblings in 1 database
> call. Currently, if you load a list of objects, you still need to loop
> through the objects to load the children/sibling separately. This will
> help in scenarios such as reporting where the developer needs to load
> large amounts of data. Since GetList(), GetChildrenList() and
> GetSiblingList() are all done in 1 call now, the performance index is
> linear w.r.t the # of children being loaded. Even without this plugin
> that we're working on, performance should not be an issue anymore.

> 2) The next big thing in 3.0 is the plugin architecture.
> You'll now notice a plugins folder that get generated by default. As
> well, we provide a default base64 plugin (see 1) above). Plugins are
> usually application side functions, i.e. they extend the functionality
> of all objects by providing a specific function. For example, a Search
> plugin provides a search function to all objects. Once this search
> plugin is installed, the developer can do $object->Search(args) and it
> do its job.

> To make the lives of plugin developers easy, we provide the POG_Base
> object that any plugin can extend. In the POG_Base we intend to
> provide generic functions that will help abstract common code.

> Note:
> in Alpha, we havent yet hooked the objects to pog_base. we intend to
> do this soon. We also are not using the functions in POG_Base within
> the generated code (for e.g. generalizing Get() and GetList() as
> mentioned by Andy above) because there is a performance penalty
> (albeit a small one) when doing so. Plugins, however, should use these
> base functions as they are not 'generated'.

> We are also working on standardizing the database class (note that
> even PDO code will now use a database class) so that plugins are
> easily compatible with all 3 php versions we support: php 4, php5 and
> php 5+pdo.

> Plugins can also be Setup-side plugins (as is the base64 plugin we
> provide). i.e they do not provide any function to the object. Instead,
> their purpose is to facilitate manipulation of the database. Of
> course, plugins can also have both (setup side and application side)

> Other smaller changes
> - Delete() now has 2 flags when relations are involved : $deep and
> $across. See this for more details:http://groups.google.com/group/Php-Object-Generator/browse_thread/thr...

> - session_start has been removed from configuration

> - GetList now allows comparison on column names to support comparisons
> between columns and the IN operator. For example if you want to get
> the list of all objects where 1 attribute > than the other, use the
> mysql quote around the value such as (Note the ` character around
> createdon)

> array(" lastUpdatedOn", ">", "`createdon`")

> - standardized the API for getlist, getchildrenlist and getsibling
> list: they all return everything if no arguments are passed.

> Mostly, what we're working on for BETA are:

> - churn out some plugins and improve pog_base, class.database.php so
> that plugin development is easy and intuitive.
> - see if we can refactor some code into pog_base without affecting
> performance
> - add some other default functions to each object such as GetCount(),
> etc.
> - clean up
> - new design for the generator website.

> Regards,
> The POG Team.

> On Apr 19, 2:59 am, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:

> > Joel,

> > Good to get a look at it. Thanks.

> > First thoughts based on 5 minutes reading the code that it generates...

> > (1) Generated class code uses calls to POG_Base::Unescape and
> > POG_Base::Escape rather than $this->Unescape and $this->Escape which
> > means I can't alter the standard behaviour of these functions in my
> > subclasses

> > (2) What part of Get() and GetList() could not be generalised and put in
> > the base class (reducing the configuration of subclasses almost to the
> > definition of the pog_attribute_type array since the same applies to the
> > Save and Delete routines)?

> > (3) A POG_Base routine along the lines of FillFieldFromDBResult(
> > $fieldName, $result) and GetFieldForSQLStatement($fieldName) would give
> > the user some hooks to do per-field Escape/Unescape logic.
> > Alternatively, changing the signature of Escape/Unescape (and using
> > $this-> as in 1 above) would give the same possibility.

> > Later,

> > Andy

> > -------------
> > Yada, yada, yada...

> > Roslin Institute is a company limited by guarantee, registered in
> > Scotland (registered number SC157100) and a Scottish Charity (registered
> > number SC023592). Our registered office is at Roslin, Midlothian, EH25
> > 9PS. VAT registration number 847380013.

> > The information contained in this e-mail (including any attachments) is
> > confidential and is intended for the use of the addressee only.   The
> > opinions expressed within this e-mail (including any attachments) are
> > the opinions of the sender and do not necessarily constitute those of
> > Roslin Institute (Edinburgh) ("the Institute") unless specifically
> > stated by a sender who is duly authorised to do so on behalf of the
> > Institute.

> > > -----Original Message-----
> > > From: Php-Object-Generator@googlegroups.com
> > > [mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel
> > > Sent: 19 April 2007 03:43
> > > To: Php Object Generator
> > > Subject: [Php-Object-Generator:1038] POG 3.0 alpha available

> > > 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.

> > > Please send us your feedback. It will help us a lot. Soon,
> > > we'll add some documentation to this thread about what has
> > > changed, what to look for, things we're still planning to improve etc.

> > > Thanks for your patience and support,
> > > The POG Team.

> > > Thread references:
> > >http://groups.google.com/group/Php-Object-Generator/browse_thr

> > ead/thread/8d1e6d6016bbdd5e>http://groups.google.com/group/Php-Object-Generator/browse_thr

> > ead/thread/6210655c137fa200

> > - Hide quoted text -

> > - Show quoted text -- Hide quoted text -

> > - Show quoted text -- Hide quoted text -

> - Show quoted text -