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.
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.
> 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.
Very well done joel, pog 3 seems very interesting :) I will surely play with the plug-ins interface and see what I can get out of it.
Regards,
Paris Paraskeva Managing Director M.E. & E. United Worx Ltd 33, Apostolou Pavlou Avenue, Office 103, 8046 Paphos, Cyprus Tel.: +357 26220707, +357 26221313, Mob.: +357 99575501 Fax.: +357 26221002 pa...@unitedworx.com www.unitedworx.com
The information contained in this email message(and any attachments) is legally privileged and confidential information intended only for the use of the addressee(s) listed on this email. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution or copy of this email is strictly prohibited. If you have received this email in error, please notify us by telephone or email on the contact details shown on the end of this email. Thank you.
[mailto:Php-Object-Generator@googlegroups.com] On Behalf Of Joel Sent: Thursday, April 19, 2007 5:43 AM 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.
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.
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.
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)
- 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:
> 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.
> > 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.
1) Right, I understand, and i think you're right, we can change it to $this->escape in the objects. As mentioned in my post above, we haven't yet hooked up the generated objects with POG_Base. We'll hook them up before beta.
2) For performance reasons, Get and GetList were made as explicit as possible. i.e. no lookups at all during runtime. (let the generator do what a generator does best). However, we still intend to create those functions that will allow internal lookups for the purpose of plugins.
3) Agreed, there are already some functions there such as Fetch objects which will take the result of a select SQL statement and transform the result into an array of objects. This, arguably was to be used both in Get() and GetList() but (and it does work correctly), but i think we'll leave the usage to plugins since we want the core methods to be as fast as possible. Nothing has been set in stone though..
regards, Joel
On Apr 19, 10:10 am, Joel <joel...@gmail.com> wrote:
> 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.
> 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)
> - 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.
> > > 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.
Just reading through the code right now, the following comes to mind.
1) Does __call() work on php4 objects without jiggery-pokery? Reading the php.net docs, the implication is that we need to call 'overload()' on the POG objects before __call() gets registered. I can't see where this is being done, nor do I know if this needs to be done on every object or doing it just on the base class will work.
2) The Base64 plugin feels clunky to me. All the instructions in the configuration file seem like an awful rigmarole to make users go through. I recognise that having the encoding in the database should be quicker, but at what price in complexity?
I will have another look at it tomorrow.
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 17:22 > To: Php Object Generator > Subject: [Php-Object-Generator:1043] Re: POG 3.0 alpha available
> re:Andy
> 1) Right, I understand, and i think you're right, we can > change it to $this->escape in the objects. As mentioned in my > post above, we haven't yet hooked up the generated objects > with POG_Base. We'll hook them up before beta.
> 2) For performance reasons, Get and GetList were made as > explicit as possible. i.e. no lookups at all during runtime. > (let the generator do what a generator does best). However, > we still intend to create those functions that will allow > internal lookups for the purpose of plugins.
> 3) Agreed, there are already some functions there such as > Fetch objects which will take the result of a select SQL > statement and transform the result into an array of objects. > This, arguably was to be used both in Get() and GetList() but > (and it does work correctly), but i think we'll leave the > usage to plugins since we want the core methods to be as fast > as possible. Nothing has been set in stone though..
> regards, > Joel
> On Apr 19, 10:10 am, Joel <joel...@gmail.com> wrote: > > Things to look for in 3.0 alpha.
> > 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.
> > 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)
> > - 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
1) Correct. the developer will need to overload the objects or we can try to do it.. haven't tried the pog_base option you outlined yet... plugins won't be as 'intuitive' in php4 as in php5+ but that's just a limitation of the language itself.
2). The explanation is clunky, and i'll try to simplify it, but honestly, it boils down to clicking a few buttons and the developers gets automatic encoding/decoding. i don't know of any other library or even method of making it simpler... And by default, encoding will be turned off because encoding will truly only be needed in a production enviroment or at certain points in the development.
The gains performance-wise are simply too much to not push the decode/ encode into the db. having personally used pog in a large application really pushed the old pog to the limit...
this can be further discussed though, and any other suggestions for simplication will be appreciated...
joel
On Apr 19, 3:34 pm, "andy law \(RI\)" <andy....@bbsrc.ac.uk> wrote:
> Just reading through the code right now, the following comes to mind.
> 1) Does __call() work on php4 objects without jiggery-pokery? Reading > the php.net docs, the implication is that we need to call 'overload()' > on the POG objects before __call() gets registered. I can't see where > this is being done, nor do I know if this needs to be done on every > object or doing it just on the base class will work.
> 2) The Base64 plugin feels clunky to me. All the instructions in the > configuration file seem like an awful rigmarole to make users go > through. I recognise that having the encoding in the database should be > quicker, but at what price in complexity?
> I will have another look at it tomorrow.
> 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 17:22 > > To: Php Object Generator > > Subject: [Php-Object-Generator:1043] Re: POG 3.0 alpha available
> > re:Andy
> > 1) Right, I understand, and i think you're right, we can > > change it to $this->escape in the objects. As mentioned in my > > post above, we haven't yet hooked up the generated objects > > with POG_Base. We'll hook them up before beta.
> > 2) For performance reasons, Get and GetList were made as > > explicit as possible. i.e. no lookups at all during runtime. > > (let the generator do what a generator does best). However, > > we still intend to create those functions that will allow > > internal lookups for the purpose of plugins.
> > 3) Agreed, there are already some functions there such as > > Fetch objects which will take the result of a select SQL > > statement and transform the result into an array of objects. > > This, arguably was to be used both in Get() and GetList() but > > (and it does work correctly), but i think we'll leave the > > usage to plugins since we want the core methods to be as fast > > as possible. Nothing has been set in stone though..
> > regards, > > Joel
> > On Apr 19, 10:10 am, Joel <joel...@gmail.com> wrote: > > > Things to look for in 3.0 alpha.
> > > 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.
> > > 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/br > owse_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:
