Re: Structures_DataGrid DataObject DataSource

From: Date: Wed, 22 Mar 2006 22:38:12 +0000
Subject: Re: Structures_DataGrid DataObject DataSource
References: 1 2  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-41943@lists.php.net to get a copy of this message
On 3/22/06, Olivier Guilyardi <ojaiml@nerim.net> wrote: > Hi Arnaud, > > arnaud sellenet bodin wrote: > > Hi ! > > I just checked the CVS (via web interface), seems work is in progress > > for the new release of SDG, nice ! > > Thanks, lots of work indeed. SDG's been through a quite long refactoring. > > > I just want to tell you about something I was thinking of in the > > DataObject DataSource file. Maybe it's still too early to talk about > > such details. Anyway I think this might still be up to date later. > > The refactoring mainly concerns the renderer layer (see bug #5859). You are > talking about the datasource layer which is the other half of SDG. So yeah, it's > a bit early, cause the current goal is to release the new renderer design.. > > > I experience some performance hits using dataobjects as a datasource > > for a SDG, if I turn formbuilder_integration to true. This is due I > > think to the many database access to get all the linked records, I > > think it could be worth optimising > > That's heavy indeed. Unfortunately, I never used the formbuilder_integration > option myself. I already integrated SDG with FB in the past, but that was before > this option. > > > Ideally would be to make joins so that all the necessary information is > > fetched from only one db query. But it might be a bit complicated and > > unstable (IMHO) > > It sounds complicated, but it certainly is the best in regard to the relational > database paradigm. > > > What I did is store the linked records in an array for caching purpose.. > > It's quite efficient with recurrent links (like country, categories > > etc...). What do you think ? it could be activated in the options > > passed to the bind() method. > > I think that it's good as well, and certainly easier to optimize than complex joins. > > IMO if the dataobject driver was modular enough you should be able to do what > you need by subclassing it. Everything that's related to fetching links should > go into methods that one can overload in order to provide his/her own > link-fetching routines. > > This way you may be able to use either joins or arrays in your customized > driver. You may be able to precisely optimize the link-fetching routines for > your specific needs. > > What do you think about this ? > Right now the DataObject driver is using FormBuilder to pull these names and it does indeed use one query per record, mostly because it was what worked and what I could get working right off the bat. It should be possibel to do this using a join, but with the way that this currently works in FormBuilder this would still be one query per row. It should also be possible to rewrite the code in the DataObject driver to use joins instead of pulling from FormBuilder, but it's going to take a recursive algorithm and some testing to make it work well. -- Justin Patrin

« previous php.pear.dev (#41943) next »